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

Doug Barton <dougb@dougbarton.us> Thu, 12 May 2011 02:21 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 03730E0681 for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 19:21:28 -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 c2i82B+QxasK for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 19:21:27 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 48A72E0662 for <dnsext@ietf.org>; 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 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 02:21:23 -0000
X-Originating-IP: 65.241.43.5
X-Sender: dougb@dougbarton.us
Message-ID: <4DCB4421.5020306@dougbarton.us>
Date: Wed, 11 May 2011 19:21:21 -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: Mark Andrews <marka@isc.org>
References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org>
In-Reply-To: <20110512015806.209E0EAF182@drugs.dv.isc.org>
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 02:21:28 -0000

On 05/11/2011 18:58, Mark Andrews wrote:
> In message<4DCB2E3F.4030701@dougbarton.us>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.  :)  http://SupersetSolutions.com/