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

Mark Andrews <marka@isc.org> Thu, 12 May 2011 01:57 UTC

Return-Path: <marka@isc.org>
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 1ECCEE087F for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 18:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 7dPerW8BPImi for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 18:57:49 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 016FDE0681 for <dnsext@ietf.org>; Wed, 11 May 2011 18:57:47 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 87C74C9512; Thu, 12 May 2011 01:57:34 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id ED835216C1E; Thu, 12 May 2011 01:57:33 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 209E0EAF182; Thu, 12 May 2011 11:58:06 +1000 (EST)
To: Doug Barton <dougb@dougbarton.us>
From: Mark Andrews <marka@isc.org>
References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us>
In-reply-to: Your message of "Wed, 11 May 2011 17:47:59 MST." <4DCB2E3F.4030701@dougbarton.us>
Date: Thu, 12 May 2011 11:58:06 +1000
Message-Id: <20110512015806.209E0EAF182@drugs.dv.isc.org>
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 01:57:50 -0000

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

> 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/
> 
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org