Subject: example DS record for SHA-256

From: Wes Hardaker <[email-masked]>
Date: Wed, 16 Nov 2005 15:15:08 -0800

Here's an example section for the recent sha-256 ID; feedback
appreciated:

(note: was TDB appendix A in -00; moved to Section 2.3 to match 4034 style)

----------------------------------------------------------------------

2.3.  Example DS Record Using SHA-256

   The following is an example DSKEY and matching DS record.  This
   DNSKEY record comes from the example DNSKEY/DS records found in
   section 5.4 of [RFC4034].

   The DNSKEY record::

   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                                fwJr1AYtsmx3TGkJaNXVbfi/
                                                2pHm822aJ5iI9BMzNXxeYCmZ
                                                DRD99WYwYqUSdjMmmAphXdvx
                                                egXd/M5+X7OrzKBaMbCVdFLU
                                                Uh6DhweJBjEVv5f2wwjM9Xzc
                                                nOf+EPbtG9DMBmADjFDc2w/r
                                                ljwvFw==
                                                ) ;  key id = 60485

   The resulting DS record covering the above DNSKEY record using a SHA-
   256 digest: [RFC Editor: please replace XXX with the assigned digest
   type (likely 2):]

   dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
                                                CEB1E3E0614B93C4F9E99B83
                                                83F6A1E4469DA50A )

----------------------------------------------------------------------

-- 
Wes Hardaker
Sparta, Inc.

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

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 17 Nov 2005 09:33:31 -0500

I just finished the draft and I have one comment on Section 3.  I don't know
if the wording "MUST perfer DS records with SHA-256..." is necessary.  It is
also rather vague for validator implementors - what happens when the SHA-256
DS RR is invalid, but there is a valid SHA-1?  Is the chain still valid?  I
think the preference language isn't necessary (local policy :) ) since most
developers know SHA-256 is stronger than SHA-1.

Also, it might be helpful for readers to include a simple table in the IANA
considerations section detailing the algorithms:

   VALUE   Algorithm               Status
     0       Reserved                -
     1       SHA-1                MANDATORY(1)
     2       SHA-256              MANDATORY
   3-255    Unassigned               -

(1) SHA-1 is still mandatory to implement and deploy for a period following
the publication of this draft to RFC status.  This is necessary for a period
of backwards compatibility until SHA-256 is more widely deployed.  See
section 4.

-------------
Or something similar.  The note may not be necessary.

Scott
****************************************
Scott Rose
Adv. Network Tech. Div., NIST
+1 301-975-8439

https://www-x.antd.nist.gov/dnssec/
****************************************

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Wes Hardaker
> Sent: Wednesday, November 16, 2005 6:15 PM
> To: [email-masked]
> Subject: example DS record for SHA-256
>
>
>

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 17 Nov 2005 20:13:54 -0500 (EST)

> developers know SHA-256 is stronger than SHA-1.

I agree with Scott -- the entire "preference" paragraph (2nd paragraph
of section 3) needs to come out.

> of backwards compatibility until SHA-256 is more widely deployed.  See

I suggest changing this to "Both SHA-1 and SHA-256 are mandatory for
resolvers to implement.  Resolvers may wish to provide a configuration
option to disable any given message digest algorithm.  DS records
should use SHA-256 and may use SHA-1, as discussed in section 4."

-- Sam

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Nov 2005 13:52:07 -0800

>>>>> On Thu, 17 Nov 2005 20:13:54 -0500 (EST), Samuel Weiler <[email-masked]> said:

Samuel> I suggest changing this to "Both SHA-1 and SHA-256 are
Samuel> mandatory for resolvers to implement.

If you're going to go down the current road that looks like the path
consensus want to take, I don't think you should say that SHA-1 is
mandatory to implement.  The new document should state that SHA-256 is
mandatory but I'm not sure you should say that SHA-1 also is
mandatory, unless you also state that this requirement doesn't come
from this document but rather that you're just quoting the other RFC(s).

Samuel> Resolvers may wish to provide a configuration option to
Samuel> disable any given message digest algorithm.  DS records should
Samuel> use SHA-256 and may use SHA-1, as discussed in section 4."

Interestingly enough, I actually didn't like the language in the
document as well but had put it in based on input received from a few
people.  I generally don't think it's wise to dictate policy.  I think
the better choice is to specify what you must implement (which you
indicated above) and potentially indicate what you must default to.
Thus, I'd think something like the following text might be better:

Validator implementations MUST implement the SHA-256 digest type.
Validator implementations MUST be able to prefer SHA-256 digest types
over SHA-1 digest types, and MUST do this by default.  Validator
implementations SHOULD provide configuration ability to specify the
proper policy to use when selecting between whether to use SHA-256 and
SHA-1 digest types when DS records of both types are available but
only one can be used to securely validate a child's DNSKEY.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Nov 2005 13:56:20 -0800

>>>>> On Thu, 17 Nov 2005 09:33:31 -0500, "Scott Rose" <[email-masked]> said:

Scott> I just finished the draft and I have one comment on Section 3.
Scott> I don't know if the wording "MUST perfer DS records with
Scott> SHA-256..." is necessary.  It is also rather vague for
Scott> validator implementors - what happens when the SHA-256 DS RR is
Scott> invalid, but there is a valid SHA-1?  Is the chain still valid?
Scott> I think the preference language isn't necessary (local policy
Scott> :) ) since most developers know SHA-256 is stronger than SHA-1.

See my response to Sam's message for a better answer to why that text
is in there and a proposed replacement.

However, in summary I agree that it should be configurable policy.
However, I personally am not sure when I'd ever allow a SHA-256 digest
to fail and I'd trust the SHA-1 digest instead.  But that's my
preference and I'm sure we could find someone that would state that's
a necessary policy to hold.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 18 Nov 2005 17:28:45 -0800

> From: Wes Hardaker [mailto:[email-masked]]
> Sent: Friday, November 18, 2005 1:56 PM
>

That's the beauty of local policy :)  Some folks might want any chain that
works - if there is some problem with the SHA-256 DS RR, then try the SHA-1
DS and proceed if it works.

If we want SHA-256 to be deployed quickly, then I agree that SHA-256 be the
only mandatory to implement algo.  And move SHA-1 to NOT RECOMMENDED or even
obsolete it.  Given the fact that upgrades could be slow (even with the 2010
date), obsoleting it now does not sound like a good idea to me.

Scott

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 20 Nov 2005 03:51:01 -0800 (PST)

Since I was not present at recent hash related government sponsored
meetings can I get a confirmation that SHA256 is considered to be 
sufficiently secure and is now recommended where SHA1 previously was
to be used?

Also will the new hash algorithm be developed and if so when should we 
expect it? Will it be 160-bit or at minimum 256-bit like SHA256?

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 21 Nov 2005 11:14:52 -0800

>>>>> On Sun, 20 Nov 2005 03:51:01 -0800 (PST), "william(at)elan.net" <[email-masked]> said:

william> Also will the new hash algorithm be developed and if so when
william> should we expect it? Will it be 160-bit or at minimum 256-bit
william> like SHA256?

There is already a internet-draft (draft-ietf-dnsext-ds-sha256-00.txt)
that describes this and specifies a full 256 bit length.

-- 
Wes Hardaker
Sparta, Inc.