Subject: [DNSOP] Proposed changes to RFC 4641: better cryptography

From: Paul Hoffman <[email-masked]>
Date: Sun, 28 Sep 2008 21:15:36 -0700

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-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 29 Sep 2008 07:41:27 -0700

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, September 28, 2008 9:15 PM
Subject: [DNSOP] Proposed changes to RFC 4641: better cryptography

>    roughly the same time, but DSA is about ten times slower for

This is a problem because of the overhFrom [email-masked]  Mon Sep 29 07:42:55 2008
From: "TS Glassey" <[email-masked]>
To: <[email-masked]>
Date: Mon, 29 Sep 2008 07:41:27 -0700
Subject: Re: [DNSOP] Proposed changes to RFC 4641: better cryptography
Sender: [email-masked]

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, September 28, 2008 9:15 PM
Subject: [DNSOP] Proposed changes to RFC 4641: better cryptography

>    roughly the same time, but DSA is about ten times slower for

This is a problem because of the oveead 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.

> https://www.irhead 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.

> https://wwwetf.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

.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