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

Doug Barton <> Thu, 12 May 2011 02:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03730E0681 for <>; Wed, 11 May 2011 19:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c2i82B+QxasK for <>; Wed, 11 May 2011 19:21:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 48A72E0662 for <>; Wed, 11 May 2011 19:21:27 -0700 (PDT)
Received: (qmail 25696 invoked by uid 399); 12 May 2011 02:21:23 -0000
Received: from unknown (HELO ( by with ESMTPAM; 12 May 2011 02:21:23 -0000
Message-ID: <>
Date: Wed, 11 May 2011 19:21:21 -0700
From: Doug Barton <>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv: Gecko/20110429 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark Andrews <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc:, Paul Hoffman <>
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 May 2011 02:21:28 -0000

On 05/11/2011 18:58, Mark Andrews wrote:
> In message<>us>, Doug Barton writes:
>> On 05/11/2011 15:50, Francis Dupont wrote:
>>>    In your previous mail you wrote:
>>>      What Paul is (I believe) indicating is that doing the latter isn't quite in
>>>      keeping with the general spirit of the RFC, or in the "be liberal in what
>>>      you accept" philosophy.
>>> =>   The RFC says:
>>>      Validator implementations SHOULD ignore DS RRs containing SHA-1
>>>      digests if DS RRs with SHA-256 digests are present in the DS RRset.
>>> so it doesn't say "valid" SHA-256 digests or something else.
>>> I am sorry but there is one possible interpretation of the text,
>>> of course we can agree the text is bad (:-). BTW I already signaled
>>> there is no guideline for other (than SHA-1 and SHA-256) digest
>>> algorithms so anyway a new document is needed...
>> A) Insert obligatory rant about why "should" and "may" should never be
>> used in standards documents.
>> 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.
>> I think we could have a fine "angels-on-the-head-of-a-pin" debate about
>> what "present" means in the RFC text, 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.
> Actually that was exactly the intent.  It was don't trust SHA-1 at all
> if SHA-256 is present.

Ok, so I guess we *do* need to have a debate about what "present" means. 
:)  To me, "it doesn't work" would indicate "!present," but I suppose 
reasonable minds could differ.

>> One could imagine a theoretical downgrade attack where the attacker
>> somehow got access to the parent and was able to invalidate the SHA-256
>> DS so that they could do their nefarious magic with the SHA-1 version,
>> but if you could gain that kind of access to the parent wouldn't you
>> have better ways to cause mischief?
> The senario is that you have broken SHA-1 and can construct a working
> DNSKEY which matches what the parent is publishing but have not
> broken SHA-256.  If you trust SHA-1 then the attack works.  It you
> don't trust SHA-1 the attack fails.  The rfc is assuming this will
> happen before the reverse and is telling implementors to code for
> it as if it was a current threat.

I get that, but I think we differ on the issue of "present." If there is 
a _working_ SHA-256 DS I agree with you completely.


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