Subject: draft SHA-256 for DS RRs comments

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

--
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: Fri, 18 Nov 2005 17:28:45 -0800

> From: Wes Hardaker [mailto:[email-masked]]
> Sent: Friday, November 18, 2005 1:56 PM
>
> 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.
>

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