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

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Dec 2005 11:16:33 +1100

Looks good.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Wed, 14 Dec 2005 13:41:50 -0500

I think there is a typo in Section 3, second paragraph:

"Validator implementations MUST, by default, ignore DS RRs containing SHA-1
digests if DS RRs with SHA-256 digests are present in the DS RRset.  THis
behavior SHOULD be the default."

Did the group decide on MUST, or SHOULD?

Scott

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

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 16 Dec 2005 09:19:28 -0500

I realize this doesn't answer the question "did the group?":

Isn't everything subject to local policy?  (I think so.)
For the sake of interoperability, is this important?  (I don't think so.)

Therefore I my opinion is that it should be SHOULD.  As in a recommendation.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: David Blacka <[email-masked]>
Date: Fri, 16 Dec 2005 09:37:41 -0500

> Therefore I my opinion is that it should be SHOULD.  As in a  

I agree.  This is a recommendation, not a requirement.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Rob Payne <[email-masked]>
Date: Fri, 16 Dec 2005 11:57:44 -0500

> >>Did the group decide on MUST, or SHOULD?

For what it is worth, I have reviewed the document and believe that it
is ready to progress once the language in Section 3 has been cleaned
up as Ed and David suggest.

				 -rob

---

From: Chris Thompson <[email-masked]>
Date: Fri, 16 Dec 2005 18:08:35 +0000 (GMT)

> Did the group decide on MUST, or SHOULD?

Apart from that, the second sentence seems tautologous or contradictory
(depending on whether the MUST/SHOULDs match or not). What is the intent
of saying

   1. Validator implementations MUST/SHOULD, by default, do X.
   2. This behaviour MUST/SHOULD be the default.

? Is some subtlety about the distinction between "implementations" and
"validator implementations" escaping me here?

-- 
Chris Thompson
Email: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Dec 2005 14:21:01 -0500

> Did the group decide on MUST, or SHOULD?

My understanding of the discussion was that we agreed that the
default needs to be SHA-256, but that this is ultimately a policy
decision, so operators need to have the ability to instead prefer
SHA-1 if they want.  Some of us were arguing that this entailed the
SHOULD formulation; at least one person argued that such a weakness
is too great, and wanted the MUST formulation.  Since this is just a
default setting requirement, I can't see that it makes any
difference, in light of the sentence following the "SHOULD be the
default":

   Validator implementations MAY provide configuration settings that
   allow network operators to specify preference policy when
   validating multiple DS records containing different digest types.

So I don't care which one we settle on, as long as the requirement
doesn't get any stronger such that it alters the ability for
operators to do something else, if they have to.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 26 Dec 2005 12:32:13 -0800

>>>>> On Fri, 16 Dec 2005 09:19:28 -0500, Edward Lewis <[email-masked]> said:

Edward> I realize this doesn't answer the question "did the group?":

Edward> Isn't everything subject to local policy?  (I think so.)  For
Edward> the sake of interoperability, is this important?  (I don't
Edward> think so.)

Edward> Therefore I my opinion is that it should be SHOULD.  As in a
Edward> recommendation.

Ed, I think the wording issues that Chris pointed out were the real
issue.  Thus the new text I think fixes your problems:

      <t> Validator implementations MUST be able to ignore DS RRs
	containing SHA-1 digests if DS RRs with SHA-256 digests are
	present in the DS RRset. This behavior SHOULD be the default.
	Validator implementations MAY provide configuration settings
	that allow network operators to specify preference policy when
	validating multiple DS records containing different digest
	types.</t>

It was unclear from both you and David if the MUST you had issues with
was in relation to the ability or the default (since the original
sentence sort of implied both).  The above means the ability must be
there (which I think the WG previously agreed upon) but only SHOULD be
on by default and MAY be configurable.  That actually leaves room for
implementations to do whatever they want (which I'm not sure is good
since they can prefer SHA-1 over SHA-256 without configuration to do
otherwise, but hey...)

-- 
Wes Hardaker
Sparta, Inc.

---

From: David Blacka <[email-masked]>
Date: Mon, 26 Dec 2005 23:36:41 -0500

> since they can prefer SHA-1 over SHA-256 without configuration to do

The use of MUST means that, if an implementation doesn't do the  
thing, something Will Not Work.  All of this language is about  
preferring SHA-256 to SHA-1.  This is a Good Idea, but none of this  
is necessary for interoperability.  Thus, SHOULD or RECOMMENDED is  
the appropriate level for the entire paragraph.

--
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 26 Dec 2005 22:18:15 -0800

>>>>> 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 this  
David> is necessary for interoperability.  Thus, SHOULD or RECOMMENDED is  
David> 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...

-- 
Wes Hardaker
Sparta, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Dec 2005 08:25:11 -0500

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

---

From: David Blacka <[email-masked]>
Date: Tue, 27 Dec 2005 09:47:15 -0500

> (which then affects interoperability).

True.

> IMHO, it should stay as a MUST.  But...  I of course will follow the

Ok, let me step back a little.  Part of what I'm arguing is that the  
paragraph, as currently constructed just isn't using MUST in an  
appropriate way.  Statements like "client MUST have feature X, SHOULD  
use feature X, but MAY choose not to" directly translate to "SHOULD  
use feature X".  The sentence "...implementations MUST be able to  
ignore DS RRs..." is not meaningful in a protocol document.  Or, in  
other words, pure software requirements have no place in a protocol  
document.

The document can say one of two things:

a) validators MUST ignore SHA-1 DSs when SHA-256 DS are present, or
b) validators SHOULD ignore SHA1-1 DSs ...

Currently, your paragraph is actually saying b.

My previous arguments were that b is the correct choice.

> attack is actually executable against SHA-1...

Which is at least partly why b is the correct choice.

So, to conclude, I suggest that your paragraph just boil down to:

   <t>Validator implementations SHOULD ignore DS RRs containing SHA-1  
digests if DS RRs with SHA-256 digests are present in the DS RRset.</t>

---

From: Alex Bligh <[email-masked]>
Date: Tue, 27 Dec 2005 16:26:29 +0000

--On 27 December 2005 09:47 -0500 David Blacka <[email-masked]> 
wrote:

> use feature X, but MAY choose not to" directly translate to "SHOULD  use
> feature X".

On reflection, I'd tend to agree.

Alex

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 Dec 2005 09:49:35 -0800

>>>>> On Tue, 27 Dec 2005 09:47:15 -0500, David Blacka <[email-masked]> said:

David> Ok, let me step back a little.  Part of what I'm arguing is
David> that the paragraph, as currently constructed just isn't using
David> MUST in an appropriate way.  Statements like "client MUST have
David> feature X, SHOULD use feature X, but MAY choose not to"

That's not what it says, actually...

What is says is "clients lacking a choice MUST prefer SHA-256.
clients with a choice SHOULD make it the default to prefer SHA-256."

However....

David> So, to conclude, I suggest that your paragraph just boil down to:

David> <t>Validator implementations SHOULD ignore DS RRs containing SHA-1  
David> digests if DS RRs with SHA-256 digests are present in the DS RRset.</t>

There are at least enough people in this discussion that are in
agreement with you that I will likely change the wording...  What
needs to be done, however, is to go back in the archives to review
what people in the previous conversations (that led to the current
text) had to say to see if we're everyone is (mostly) in agreement or
whether there is now a split between the old and new conversations.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 Dec 2005 09:46:46 -0800

>>>>> On Tue, 27 Dec 2005 08:25:11 -0500, Edward Lewis <[email-masked]> said:

Edward> I cringe when I hear "security will not work" because I have never 
Edward> once heard from a seasoned security practioner "if you do things this 
Edward> way, you will be secure."

Very true.  What you tend to hear instead is "if you do things this
way, you *won't* be secure".  Or in this case "if you do things this
way (SHA-1), you're likely less secure than you would be if you use
this other thing (SHA-256).  At least right now.  Maybe."

Edward> I wouldn't be surprised if, in 5 years, I hear that SHA-256 is
Edward> beaten and now SHA-1 is more secure.

Always a possibility.

-- 
Wes Hardaker
Sparta, Inc.