Subject: Fast Track document: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Fri, 11 Nov 2005 16:51:55 -0500

<DNSEXT co-chair hat on>
Based on guidance from the security area, we will be fast tracking this
document. DS algorithm has been determined to be the weakest link in
the DNSSEC chain, thus we are adding new stronger algorithm now and retiring
SHA-1 from use in 2 years after this is published as RFC.

The expectation is that there will one more algorithm roll in about 5 years
when new generations of digest algorithm(s) has been reviewed and
standardized.

Please send comment on this version NOW to namedroppers,
the plan is to start DNSEXT WG last call around Nov 20'th.

The plan is to update digest algorithms used in signatures (RRSIG)
in the near future, along with the retirement of TSIG/MD5.

         Olafur (DNSEXT co-chair)

At 15:50 11/11/2005, [email-masked] wrote:
>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-00.txt
>         Pages           : 7
>         Date            : 2005-11-11
>
>    This document defines the use of the SHA-256 digest type for creating
>    digests of DNSKEY Resource Records (RRs).  These digests can then be
>    published in Delegation Signer (DS) resource records (RRs) by a
>    parent zone.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ds-sha256-00.txt

--
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: Roy Arends <[email-masked]>
Date: Sun, 13 Nov 2005 16:02:14 +0100

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Wes,

On Fri, 11 Nov 2005 [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 	Title		: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
> 	Author(s)	: W. Hardaker

Good work. I'd like to see this advanced asap.

However, I'd like to see (something like) the following text added in
section 4 as a motivation for supporting both digest types for two years:

4.  Deployment Requirements

   If a validator does not support the SHA-256 digest type in an
   authenticated DS RRset, then the validator has no supported
   authentication path leading from the parent to the child.  The
   resolver should treat this case as it would be the case of an
   authenticated NSEC RRset proving that no DS RRset exists, as
   described in RFC 4035, section 5.2.

   Therefore, deployments SHOULD publish both SHA-1 and SHA-256
   based DS records for 2 years from the publication date of this
   RFC (XXX: RFC Editor: Please insert the calculated date here).

Regards,

Roy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 15 Nov 2005 13:15:03 -0800

>>>>> On Sun, 13 Nov 2005 16:02:14 +0100, Roy Arends <[email-masked]> said:

Roy> Good work. I'd like to see this advanced asap.

Thanks, though the incentive came from Olafur and Olaf to be honest.
They wanted someone to do it and I said I could have it done by the
end of the plenary...  (I submitted it shortly after the second one).

Roy> However, I'd like to see (something like) the following text
Roy> added in section 4 as a motivation for supporting both digest
Roy> types for two years:

Thats good looking starting text.  I've added it and modified it
slightly.  Feed back appreciated:

   If a validator does not support the SHA-256 digest type in an
   authenticated DS RR and no other RR exists in the DS RRset with a
   digest type that it supported, then the validator has no supported
   authentication path leading from the parent to the child.  The
   resolver should treat this case as it would be the case of an
   authenticated NSEC RRset proving that no DS RRset exists, as
   described in [RFC4035], section 5.2.

   Because zone administrators can not control the deployment support of
   SHA-256 in deployed validators that may referencing any given zone,
   deployments SHOULD publish both SHA-1 and SHA-256 based DS records
   for 2 years from the publication date of this RFC (XXX: RFC Editor:
   Please insert the calculated date here).

(I'm generally thinking that we should avoid document feature creep,
and stick to the solid facts most of the time.  Arguing for why this
and why that can fill a document and most of the existing documents
already cover this, so...  But the above I think is very worth
stating.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Wed, 16 Nov 2005 23:54:17 -0500

As this might have got lost among the many AAAA messages.
Please read and comment
         if the approach is reasonable
         if the time values are acceptable

Remember this Draft is going to attempt to get through the IETF in
record time, last call will start once version 01 is issued later
this week.

         Olafur

  At 16:15 15/11/2005, Wes Hardaker wrote:

><snip>

---

From: David Conrad <[email-masked]>
Date: Wed, 16 Nov 2005 21:10:08 -0800

>>    Please insert the calculated date here).

I remain unconvinced that supporting something for 2 years that has  
had infinitesimal deployment to date by requiring people to deploy  
something that they shouldn't use makes any sense at all.  If you  
want to kill SHA-1, kill it.  Don't make it a zombie that will never  
go away.

Rgds,
-drc

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 17 Nov 2005 00:04:34 -0800

>>>>> On Wed, 16 Nov 2005 21:10:08 -0800, David Conrad <[email-masked]> said:

David> I remain unconvinced that supporting something for 2 years that has  
David> had infinitesimal deployment to date by requiring people to deploy  
David> something that they shouldn't use makes any sense at all.  If you  
David> want to kill SHA-1, kill it.  Don't make it a zombie that will never  
David> go away.

There is a reason I listed it as a "SHOULD".

I'm actually not sure it'll pass IESG review anyway.  There are many
who think than putting mandatory words in there for deployment is
actually not possible.  Maybe a lower-case should would be better?

-- 
Wes Hardaker
Sparta, Inc.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Nov 2005 12:52:31 +0200 (EET)

> actually not possible.  Maybe a lower-case should would be better?

Aye.  The documents should be clear on whether such statement is a) an 
operational recommendation, or b) an implementation requirement. 
Typically, it can't be both.

Using uppercase keywords for operational recommendation easily adds 
confusion with b), so it may be better to reword for clarity and/or 
use lowercase.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Nov 2005 09:22:34 -0500

At 12:52 +0200 11/17/05, Pekka Savola wrote:

>operational recommendation, or b) an implementation requirement. Typically, it
>can't be both.

Tangential to the topic but to reinforce this conundrum, I have been 
sitting through IPv6 discussions in the RIRs.  They get tripped up 
confusing "protocol necessities" against "what the protocol designers 
think is the way this will work."  To be specific, is a /48 something 
that every house should have because there is a protocol need for it, 
now or in the future, or is it a number that seems to be the easiest 
to manage? Whenever that comes up, the discussion bounces from 
operator practices to protocol engineering.

It's becoming apparent to me that we (the DNS protocol WG) ought to 
just specify the components of the protocol and document the pros and 
cons of each element.  When it comes to saying "use this element [say 
SHA-256]" leave that to an operations forum.  Whether that is DNSOP 
or external to the IETF I won't recommend.  But the only expertise we 
should count on in this WG is on protocol engineering.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Thu, 17 Nov 2005 10:03:57 -0500

At 09:22 17/11/2005, Edward Lewis wrote:
>just specify the components of the protocol and document the pros 
>and cons of each element.  When it comes to saying "use this element 
>[say SHA-256]" leave that to an operations forum.  Whether that is 
>DNSOP or external to the IETF I won't recommend.  But the only 
>expertise we should count on in this WG is on protocol engineering.

<Chair hat on>
This is first of at least DS two algorithm rollovers we should  get
the procedure some thought and try to do the "correct" thing, so when the
second one is performed we use the same procedure.
The two rollovers are this one (SHA256) and the outcome selection of new
generation of digest algorithm by NIST in about 5 year time frame.

Protocol action:
For existing DS alg=1 that is to be obsoleted what should the document say:
A. It is obsoleted ?
B. It is obsoleted in 2 or more years ?
C. Should the not obsolete it ?
D. other

Operational guidance:
1. As it is harder update code in validators forcing but cheap to generate
and distribute DS records, the cost for parents to list multiple DS is low.

2. On the other hand deployment is almost nil so forcing the issue may be a
good thing.

3. As DS sets are small (compared to signatures) listing each trust anchor
multiple times to help old implementations may be a good thing but only for
a "limited" time.

4. Say nothing

5. Other option not listed above

please make some statements about applicability of these options

<Chair hat off>

         Olafur

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 17 Nov 2005 07:01:15 -0800

>>>>> On Thu, 17 Nov 2005 12:52:31 +0200 (EET), Pekka Savola <[email-masked]> said:

>> actually not possible.  Maybe a lower-case should would be better?

Pekka> Aye.  The documents should be clear on whether such statement
Pekka> is a) an operational recommendation, or b) an implementation
Pekka> requirement.  Typically, it can't be both.

I've changed the section title to "deployment considerations" and
changed the "SHOULD" to a "should" which I think should alleviate the
concerns.  (?)

-- 
Wes Hardaker
Sparta, Inc.

---

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

>          if the time values are acceptable

I'd prefer to see a weaker recommendation, if any at all, per the last
paragraph below.

> >    authenticated DS RR and no other RR exists in the DS RRset with

The above is correct, but 4035 is not completely clear on how to
handle unknown algorithms, as is discussed in section 3.1 of
draft-ietf-dnsext-dnssec-bis-updates-01.  I think a reference to that
section of bis-updates would be a good idea.

Some have suggested that we should go ahead and push out bis-updates
sooner rather than later, figuring it's useful as-is and we can always
push a new document with more clarifications later.  I support that --
I see no reason why the docs couldn't both advance quickly and
together.

> >    Please insert the calculated date here).

I want to see a weaker recommendation here, perhaps even no
recommendation.  "May want to considere publishing both for some time,
while being aware of SHA-1's potential weaknesses".  If any stronger
recommendation is kept, then the security considerations section needs
to point out that we're encouraging a door to be left open.

-- Sam

---

From: Roy Arends <[email-masked]>
Date: Fri, 18 Nov 2005 09:40:53 +0100 (CET)

> section of bis-updates would be a good idea.

Actually, when rfc4035 section 5.2 discusses unknown algorithms, it does 
not specifically identify the signing algorithm. It reads "any of the 
algorithms listed in an authenticated DS RRset". This definition, imho, 
includes digest algorithms as well, which makes section 3.1 of bis-updates 
redundant, or at most a clarification of a text that might be perceived 
as ambiguous, but definitly not an update.

> I see no reason why the docs couldn't both advance quickly and

I think, as per my explanation above, that new digest types and 
bis-updates are orthogonal. I'd rather wait with bis-updates until we have 
more deployment experience.

I do _not_ want to wait with sha-256, and I really do _not_ want to make 
sha-256 dependent on bis-updates.

Roy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Nov 2005 14:00:21 -0800

>>>>> On Fri, 18 Nov 2005 09:40:53 +0100 (CET), Roy Arends <[email-masked]> said:

Roy> I do _not_ want to wait with sha-256, and I really do _not_ want to make 
Roy> sha-256 dependent on bis-updates.

If I say "ditto" do I have to claim to be an AOL user, or is that
solely reserved for "me too"  responses.  I've never been too clear on
that.

I don't think that a bis-update that includes a new mandatory
algorithm is truly a good way to go forward, as it would require
cycling at proposed.  I'm not sure the rest of the bis-update thought
would require that.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Samuel Weiler <[email-masked]>
Date: Sun, 27 Nov 2005 11:48:51 -0500 (EST)

> cycling at proposed.  I'm not sure the rest of the bis-update thought

It sounds like we may be talking about different things: I'm not
talking about adding this new digest algorithm to bis-updates.  I'm
suggesting that the ds-sha256 doc refer to the discussion in
bis-updates of handling unknown digest algorithms.  I made that
suggestion because the proposed text I was writing about (the section
4 text you proposed on 15 November) referred to a section of 4035 that
doesn't adequately discuss unknown _digest_ algorithms.

Another option, and one which avoids a reference to bis-updates, is to
include text in ds-sha256 similar to what's in bis-updates section 3.2
-- make this doc, in addition to defining a new digest algorithm,
explicitly tell resolvers what to do when they see an unknown (or
unsupported/disabled) one.

-- Sam

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Nov 2005 17:03:53 -0800

>>>>> On Sun, 27 Nov 2005 11:48:51 -0500 (EST), Samuel Weiler <[email-masked]> said:

>> cycling at proposed.  I'm not sure the rest of the bis-update thought

Samuel> It sounds like we may be talking about different things: I'm not
Samuel> talking about adding this new digest algorithm to bis-updates.  I'm
Samuel> suggesting that the ds-sha256 doc refer to the discussion in
Samuel> bis-updates of handling unknown digest algorithms.

I don't think referencing a document that has no timeline associated
with it would be a good thing...

Samuel> Another option, and one which avoids a reference to
Samuel> bis-updates, is to include text in ds-sha256 similar to what's
Samuel> in bis-updates section 3.2
Samuel> -- make this doc, in addition to defining a new digest algorithm,
Samuel> explicitly tell resolvers what to do when they see an unknown (or
Samuel> unsupported/disabled) one.

I could copy it if there is consensus to do so, but I think it'd be
better to define it without a huge amount of discussion and let that
be defined in the bis-update when it's published.

-- 
Wes Hardaker
Sparta, Inc.