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

In message <4DCB2E3F.4030701@dougbarton.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