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

Doug Barton <> Thu, 12 May 2011 00:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39C15E084F for <>; Wed, 11 May 2011 17:48:06 -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 C4nYAM3aSCCe for <>; Wed, 11 May 2011 17:48:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 57989E0711 for <>; Wed, 11 May 2011 17:48:05 -0700 (PDT)
Received: (qmail 10425 invoked by uid 399); 12 May 2011 00:48:00 -0000
Received: from unknown (HELO ( by with ESMTPAM; 12 May 2011 00:48:00 -0000
Message-ID: <>
Date: Wed, 11 May 2011 17:47:59 -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: Francis Dupont <>
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 00:48:06 -0000

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.

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?



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