See below a small feedback from an "applied cryptography" perspective.
In essence, I agree with Eric.
Paul Wouters wrote:
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.
Either of two things:
(A) Some threat/vulnerability analysis is assumed behind a DNSOP-type
recommendation, and then *I* claim that 1024 RSA modulus cycling every
month is really an overkill. (I have unpublished written material
supporting this view.)
- or -
(B) Some authority (you referred to NIST which seems to refer to
academic-community factorization exploits, wherein the academic
community declare themselves unable to digress about "activities that
take or may take place behind closed doors, such as at government
laboratories" [1]) decided that 1024 was sufficient. There is no basis
other than blind faith in the authority reputation for selecting 1024
and not e.g. 3600 for a given field of use.
[1] Joppe W. Bos, Marcelo E. Kaihara, Thorsten Kleinjung, Arjen K.
Lenstra, and Peter L. Montgomery, "On the Security of 1024-bit RSA and
160-bit Elliptic Curve Cryptography", version 2, August 7, 2009, 18
pages (published on pages 43-60 in "Comments on the Transition Paper"
available at
http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transition_comments_7242009.pdf,
which was listed at http://csrc.nist.gov/groups/ST/key_mgmt/index.html).
Basically, you adhere to (B) and suggest
1024-bits/1-month-cryptoperiod, hence you inflate the requirements over
NIST's.
Thus, in *my* opinion, you induce a waste of DNSSEC bandwidth / CPU time
/ DNS operations overhead (i.e. rollover management).
(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
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
