[dns-operations] DNSKEY format and RSA keys curiosity

Viktor Dukhovni ietf-dane at dukhovni.org
Fri Apr 27 01:04:27 UTC 2018

In the below DNSKEY RRset, the first RSASHA256 KSK is a truncation to
its exponent + 304 key bits of the second (2048-bit) RSASHA256 KSK.
What's interesting is that the truncation happens at exactly the
point where "dig" by default inserts whitespace in the presentation
form of the key:

  and24.ru. DNSKEY 257 3 8
  and24.ru. DNSKEY 257 3 8

This strongly suggests some sort of cut/paste error, in which
part of the the full 2048-bit key somehow got added to the zone's
DNSKEY RRset, and in this case even DS RRs were registered to match
both the full and truncated key:

  and24.ru. DS 3760 8 2 BC6F6F68F68888C46ED7D1E71648EC8C201E218DA4B37012BDCAEA9E 6D09E256
  and24.ru. DS 20685 8 2 E7547FD8226E57217DEEE54F5E383B7545E789B7B7E5A7AFA5B29C51 8F2F7889

The unfortunate thing is that the truncation is not directly detectable
with the DNSSEC RSA key format.  Unlike the SPKI ASN.1 format, the
DNSSEC RSA key format has no explicit length for the modulus, it is just
the rest of the RDATA value after the exponent length and exponent.

This problem is RSA-specific, as the various EC algorithms have
fixed-length keys, and so one can check for inadvertent truncation.

Perhaps a more robust format could have been chosen for RSA, though
admittedly the problem looks very rare.  In over 11 million RSA
records (of zones with at least one working KSK) this looks like the
only instance of the problem.  [ I don't store data on zones where
the DNSKEY RRset lookup fails validation. ]


More information about the dns-operations mailing list