[dns-operations] DNSKEY format and RSA keys curiosity

[Viktor Dukhovni]

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
    AwEAAc4MuuKEwSsGfwxRVdgEYG+TJZAepJGB/3Z3z7fkJHJA/SXmzz3V
  and24.ru. DNSKEY 257 3 8
    AwEAAc4MuuKEwSsGfwxRVdgEYG+TJZAepJGB/3Z3z7fkJHJA/SXmzz3V
    3uPaYC2Ct9Zbm32o2/Cq1esil56fldDTE8UVlOQUnARkjHdKfocQ60Fw
    4bAf9aT+Bx/Z7YhnA/vGdmDCemVVb5enIPQyDlVhFgGd0Hs3/vILt0Yg
    uERcyO3/78eh3iE24BRJ0OB80LyPhkvl54TA2O+VSDH57XNbLJU1i4/m
    cSXVj7py7ZdI014FVfEC3KdD0mpo/Z5vB3Gzuy9iAFu3gjaFDos7MkTK
    e1FGX0v6iHkbTDHWiUF1Hns9oWWdyKXn1gq2C0VRGzuc54YV2cPH++XO
    OR9DHdeG+xE=

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. ]

-- 
	Viktor.