----- Original Message -----
From: "Paul Hoffman" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, September 28, 2008 9:15 PM
Subject: [DNSOP] Proposed changes to RFC 4641: better cryptography
Remove the second bullet in 3.1.1
In 3.2, add a reference to NIST SP 800-90 after the reference to RFC
4086. The NIST document is much longer and more comprehensive.
In the first paragraph of 3.3, remove "or cryptanalysis".
Remove the third paragraph of 3.3.
Combine the first three paragraphs of 3.4 (about signature
algorithms), and eliminate elliptic curve cryptography was never
defined for DNSSEC:
There are currently two types of signature algorithms that can be
used in DNSSEC: RSA and DSA. Both are fully specified in many
freely-available documents, and both are widely considered to be
patent-free. The creation of signatures with RSA and DSA takes
roughly the same time, but DSA is about ten times slower for
signature verification.
This is a problem because of the overhead relative to EC relative to RSA
technologies. EC being much lower than the comparable RSA singing. I suggest
that the type of Crypto is going to change and because of that it needs to
be modular such that when new crypt alg's are qualified they can just be
plugged into the framework.
Combine the last two paragraphs of 3.4 (about hashes) and correct the
information on hashes:
We suggest the use of either RSA/SHA-1 or RSA/SHA-256 as the
preferred signature algorithms. Both have advantages and
disadvantages. RSA/SHA-1 has been deployed for many years, while
RSA/SHA-256 has only begun to be deployed. On the other hand, it
is expected that if effective attacks on either algorithm appear,
they will appear for RSA/SHA-1 first. RSA/MD5 should not be
considered for use because RSA/MD5 will very likely be the first
common-use signature algorithm to have an effective attack.
Replace all of 3.5 with:
DNSSEC signing keys should be large enough to avoid all know
cryptographic attacks during the lifetime of the key. To date,
despite huge efforts, no one has broken a regular 1024-bit key; in
fact, the best completed attack is estimated to be the equivalent
of a 700-bit key. An attacker breaking a 1024-bit signing key
would need expend phenomenal amounts of networked computing power
in a way that would not be detected in order to break a single key.
Because of this, it is estimated that most zones can safely use
1024-bit keys for at least the next ten years. A 1024-bit
asymmetric key has an approximate equivalent strength of a symmetric
80-bit key.
Keys that are used as extremely high value trust anchors, or
non-anchor keys that may be difficult to roll over, may want to use
lengths longer than 1024 bits. Typically, the next larger key size
used is 2048 bits, which have the approximate equivalent strength
of a symmetric 112-bit key. In a standard CPU, it takes about four
times as long to sign or verify with a 2048-bit key as it does with
a 1024-bit key.
Another way to decide on the size of key to use is to remember that
the phenomenal effort it takes for an attacker to break a 1024-bit
key is the same regardless of how the key is used. If an attacker
has the capability of breaking a 1024-bit DNSSEC key, he also has
the capability of breaking one of the many 1024-bit TLS trust
anchor keys that are installed with web browsers. If the value of
a DNSSEC key is lower to the attacker than the value of a TLS trust
anchor, the attacker will use the resources to attack the TLS trust
anchor.
It is possible that there is a unexpected improvement in the
ability for attackers to beak keys, and that such an attack would
make it feasible to break 1024-bit keys but not 2048-bit keys. If
such an improvement happens, it is likely that there will be a huge
amount of publicity, particularly because of the large number of
1024-bit TLS trust anchors build into popular web browsers. At that
time, all 1024-bit keys (both ones with parent zones and ones that
are trust anchors) can be rolled over and replaced with larger
keys.
Earlier documents (including the previous version of this document)
urged the use of longer keys in situations where a particular key
was "heavily used". That advice may have been true 15 years ago,
but it is not true today when using RSA or DSA algorithms and keys
of 1024 bits or higher.
Remove the reference to Schneier, [17]. While it was once a very
useful book, much of the referenced material is (quite understandably)
very out-of-date. In 1.1, the reference can be replaced with RFC 4949,
"Internet Security Glossary, Version 2". The references to [17] in 3.4
and 3.5 are removed in the changes above.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.7.4/1695 - Release Date: 9/27/2008
1:11 PM
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
