On Fri, 26 Feb 2010, Eric Rescorla wrote:
For
reasons of signing speed and DNS packet length one may want to keep
keylenght at a minimal responsible length and change the key
relatively frequently while not interacting with the parent.
This statement is a non-sequiter. Sure, one may want to keep the keylength
short to improve signing speed, but since changing the key frequently doesn't
significantly improve security against analysis (as has been covered on-list
ad nauseum), the last half of the sentence doesn't make any sense.
cycling a 1024 bit RSA key every month does improve the security of a zone,
compared to not cycling the key.
Cryptanalyses is a function of time (and money). If you reduce the usable
time for attackers, their spending goes up or they will not have enough time
to break the key before it is retired. The recommended key size and time
in the document reflects current cryptographers extremely conservative
estimate of what is deemed safe by a few orders of magnitudes.
Keep in mind that some recommendations (I believe NIST is one) does not
differentiate between key usage when they recommend key sizes. For encryption,
there is a much larger required forward secrecy requirement. For signing
keys, there is none. One could publish the private TTL time after rollover.
(an interesting artifact was also the usage of an algorithm. Openswan uses
an md5 hash to calculate its vendorid hash. Not to obfuscate it, but just
to make it unique. This caused problems for FIPS certification because md5
was not allowed)
The above quoted paragraph clearly states this, despite your "covered on-list
ad nauseum" claim.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
