[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-dnsext-ds-sha256-02.txt
It is my experience that "security" features below some level of "strength" will be vetoed by the Security ADs / IESG regardless of any philosophical belief by a WG that it should be a local policy option to use weak security (although, of course, an option to dispense with the security feature entirely and be completely insecure is fine as long as the lack of security is clearly explained). For example, I was required to modify the TSIG/SHA draft to flatly prohibit truncating HMACs to less than 80 bits in order to get it through to IETF Last Call, presumably based on a belief that a strength of less than 2**40 was too weak to be called security.
Putting algorithm requirements in a separate document from the protocol specification can be a reasonable way to go and is how algorithm implementation requirements are now specified for IPSEC.
On hash functions, it is possible, but very unlikely, that SHA-1 (which could be called SHA-160) will turn out to be stronger than SHA-256. However, it is known that SHA-1 is now weaker than 2**64 for finding collisions when it was originally thought to be of strength 2**80 and, for the particular attack in question, the proven lower bound of its strength is only 2**55. This does not effect some uses, like HMAC-SHA-1, but does effect DS.
In any case, a fundamental problem is that MD5 and all the SHAs have the same basic structure. (MD5 has be severely broken to strength 2**22 instead of its design strength of 2**64.) Thus NIST has indicated it will be launching a process to devise a new generation of hash functions. However, this is not expected to complete until after 2010 and, in any case, SHA-1 was scheduled to expire as a Federal standard in 2010. So the direction of the Security Area is get out of MD5 as quickly as practical and to move to SHA-256 as quickly as convenient, keeping in mind that in 5 or 6 years we may have to migrate again to a new hash function.
Donald
-----Original Message-----
From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Edward Lewis
Sent: Tuesday, December 27, 2005 8:25 AM
To: Wes Hardaker
Cc: David Blacka; Edward Lewis; Scott Rose; namedroppers@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-02.txt
At 22:18 -0800 12/26/05, Wes Hardaker wrote:
>>>>>> On Mon, 26 Dec 2005 23:36:41 -0500, David Blacka
>>>>>><davidb@verisignlabs.com> said:
>
>David> The use of MUST means that, if an implementation doesn't do the
>David> thing, something Will Not Work. All of this language is about
>David> preferring SHA-256 to SHA-1. This is a Good Idea, but none of
>David> this is necessary for interoperability. Thus, SHOULD or
>David> RECOMMENDED is the appropriate level for the entire paragraph.
>
>There is a really large number of RFCs that have MUSTs for security
>related things. That's because without them, security Will Not Work
>(which then affects interoperability).
>
>IMHO, it should stay as a MUST. But... I of course will follow the
>consensus of the group.
>
>Though in this case I think we're not that close to the point where an
>attack is actually executable against SHA-1...
I agree with David.
The action of validation isn't an interoperability question. Either a node will do its own or it will be blindly reliant on another to perform the function (that whole AD bit issue).
I cringe when I hear "security will not work" because I have never once heard from a seasoned security practioner "if you do things this way, you will be secure." After spending a lot of time around security people, I have come to believe that security is "the goal that can not be achieved, no matter how much one works at it." I wouldn't be surprised if, in 5 years, I hear that SHA-256 is beaten and now SHA-1 is more secure.
Ultimately, I think it is a mistake for any protocol defining document or algorithm defining document to ever make a MUST out of its use or to make statements about the algorithm's "rank" amongst its peers. Whether the subject of a document is in force should be left to an operational profile document. Profiles are much easier to alter, say, to remove the broken SHA-256 when the time comes and replace it with SHA-256-and-a-half if the definitions for those two stick just to their definition.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
3 months to the next trip. I guess it's finally time to settle down and find a grocery store.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>