[dns-operations] DNSKEY format and RSA keys curiosity

[Viktor Dukhovni]

> On Apr 29, 2018, at 10:06 AM, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
>> 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.
> 
> An implementation could at least check for small key sizes and even
> small prime factors and refuse to accept the data.  It would have to
> extra checking if the modulus length were encoded in the RDATA blob,
> too, and there are arguments for and against such checks.

Yes.  Given that the exponent has an explicit (one byte) length,
which needs to be checked to not exceed the RDATA length, it would
I in hindsight have been useful to give the key a two byte length
which could also have been checked.

Yes, a sanity for small factors could might often work, the key in
question factors as:

3 * 3 * 3 * 19 * 23 * 31 * 71720591765581486724425403759908127581037458384606084822108845286828701789411278267053

Though if one is unlucky one might hit a truncated modulus without
(sufficiently) small factors.  For numbers that are 304 bits long,
around one in 211 is actually prime (I would not expect the registrar
to run primality tests on the modulus)...

In practice, it probably makes more sense to require the key to have
a minimum bit length, these days for new keys that could well be at
least 1024.  Even if one allowed 512 bits, the 304 bit KSK I ran into
could easily be rejected as a misconfiguration.

Of course a user can still misconfigure a ZSK, so perhaps it would
be better for zone file signing to fail (without some explicit
configuration forcing the checks off) when one of the RSA or DSA
keys is below a sensible minimum size.

-- 
	Viktor.