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

Doug Barton <dougb@dougbarton.us> Thu, 12 May 2011 00:48 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 39C15E084F for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 17:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 C4nYAM3aSCCe for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 17:48:05 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 57989E0711 for <dnsext@ietf.org>; 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 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 00:48:00 -0000
X-Originating-IP: 65.241.43.5
X-Sender: dougb@dougbarton.us
Message-ID: <4DCB2E3F.4030701@dougbarton.us>
Date: Wed, 11 May 2011 17:47:59 -0700
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@fdupont.fr>
References: <201105112250.p4BMoQZk020211@givry.fdupont.fr>
In-Reply-To: <201105112250.p4BMoQZk020211@givry.fdupont.fr>
X-Enigmail-Version: 1.1.2
OpenPGP: id=1A1ABC84
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 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?


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/