Subject: I-D ACTION:draft-ietf-dnsext-ds-sha256-02.txt

From: [email-masked]
Date: Tue, 13 Dec 2005 18:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
	Author(s)	: W. Hardaker
	Filename	: draft-ietf-dnsext-ds-sha256-02.txt
	Pages		: 8
	Date		: 2005-12-13
	
This document specifies how to use the SHA-256 digest type in DNS
   Delegation Signer (DS) Resource Records (RRs).  DS records, when
   stored in a parent zone, point to key signing DNSKEY key(s) in a
   child zone.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ds-sha256-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-ds-sha256-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-ds-sha256-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Tue, 27 Dec 2005 15:44:49 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Edward Lewis
Sent: Tuesday, December 27, 2005 8:25 AM
To: Wes Hardaker
Cc: David Blacka; Edward Lewis; Scott Rose; [email-masked]
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 
>>>>>><[email-masked]> 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>