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