Re: [dnsext] DNSSEC, robustness, and several DS records

Doug Barton <dougb@dougbarton.us> Thu, 12 May 2011 22:33 UTC

Return-Path: <dougb@dougbarton.us>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4F1E07C8 for <dnsext@ietfa.amsl.com>; Thu, 12 May 2011 15:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rxRb6Df1MCj for <dnsext@ietfa.amsl.com>; Thu, 12 May 2011 15:33:10 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id D85DCE0780 for <dnsext@ietf.org>; Thu, 12 May 2011 15:33:09 -0700 (PDT)
Received: (qmail 17645 invoked by uid 399); 12 May 2011 22:33:03 -0000
Received: from unknown (HELO ?65.241.43.5?) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 22:33:03 -0000
X-Originating-IP: 65.241.43.5
X-Sender: dougb@dougbarton.us
Message-ID: <4DCC601E.8090301@dougbarton.us>
Date: Thu, 12 May 2011 15:33:02 -0700
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@fdupont.fr>
References: <201105122218.p4CMIUBq006069@givry.fdupont.fr>
In-Reply-To: <201105122218.p4CMIUBq006069@givry.fdupont.fr>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dnsext@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 22:33:10 -0000

Francis, FYI your peculiar style of quoting previous text makes your 
messages very hard to read. More so when they are part of a 
traditionally quoted message like this one.


On 5/12/2011 3:18 PM, Francis Dupont wrote:
>   In your previous mail you wrote:
>
>     A) Insert obligatory rant about why "should" and "may" should never be
>     used in standards documents.
>
> =>  I don't follow your idea...

"Should" and "may" introduce ambiguity and allow different implementors 
to follow different paths, leading to multiple implementations that all 
arguably follow the spec, but don't interoperate.

>     B) I don't think it takes even the smallest leap of imagination to say
>     that if the SHA-256 DS is invalid, and the SHA-1 DS is valid, the SHA-1
>     should be used and the SHA-256 should be ignored.
>
> =>  it is not a problem of imagination: either you implement what the
> spec says or you implement something else. And IMHO the first option
> is never a "bug".

And my point is that the language of the spec is unclear, which makes 
the proper implementation questionable.

>     I think we could have a fine "angels-on-the-head-of-a-pin" debate about
>     what "present" means in the RFC text
>
> =>  present == is an element of the set

My point was that the debate centers around whether or not a DS record 
can be said to be "present," "an element of the set," or whatever other 
equivalent term you want to use; if it doesn't work. If what you are 
saying is that if it exists in any form, functional or not, then it is 
said to be "present," that's where we disagree.

>     but I have a hard time believing that the intent of the text is
>     that if you have something that works it should be ignored in favor
>     of something that doesn't.
>
> =>  but it is the intent: this is why I wrote there is no "valid"
> in the spec (where my "valid" means your "works").

And I think one could argue just as effectively that if what is meant is 
what you're interpreting then a sentence to the effect of "This is true 
even if the SHA-256 record doesn't work." should have been included. Or 
maybe not. I recognize that I could be wrong, but I don't agree that 
things are as cut and dry as you make them out to be.

> So I don't expect to see bind or unbound to change their behavior
> unless/until a new rfc is published with another spec.

And now we get to the heart of why "should" and "may" are bad for 
technical requirements documentation. If I were an implementor I could 
very easily look at the spec and say, "Francis is right, I SHOULD skip 
the SHA-1 record here whether SHA-256 works or not. But I don't like 
that interpretation of the spec, so I won't." Such an implementation 
would be just as compliant, by the letter of the spec, as one that did 
skip the SHA-1.


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/