Subject: Re: [dnsext] [Dnssec-deployment] Some more sinners... virginia.gov & onguardonline.gov

From: Matthijs Mekking <[email-masked]>
Date: Thu, 08 Sep 2011 09:49:27 +0200

Hi,

On 09/07/2011 09:37 PM, Andrew Sullivan wrote:
> On Wed, Sep 07, 2011 at 11:49:01AM -0700, Joe Abley wrote:
>> 
>> I don't think that's incorrect. It's valid for DS RRs to exist in
>> the parent referring to keys that are not yet published in the
>> child zone, for example, as a means to facilitate an emergency KSK
>> roll. So long as one DS RR provides a chain of trust to an RRSIG,
>> you're good.
>> 
> 
> The problem here is not that they're different keys, but that
> they're different algorithms.  Unbound is, IMO, being far too strict
> about this, rejecting as bogus something that is not strictly
> speaking broken, just a bad idea.  The maintainers' argument used to
> be that something so bad about some algorithm could come to light
> that this rigid rule would protect validators against algorithm
> downgrade attacks.  This seemed to me to be like setting up a shotgun
> rigged to a string on your front door knob in case someone bad
> manages to pick your deadbolt: the day you forget about the string
> will be pretty bad for you.  I thought Unbound had relaxed this rule
> to make it optional behaviour, but I could be wrong.
> 
> A
> 

Unbound indeed has relaxed its rules in 1.4.8:

	algorithm compromise protection using the algorithms signalled 	
	in the DS record. Also, trust anchors, DLV, and RFC5011 receive
	this, and thus, if you have multiple algorithms in your trust-
	anchor-file then it will now behave different than before.
	Also, 5011 rollover for algorithms needs to be double-signature
	until the old algorithm is revoked.

Before that, it also required a signature for each RRset using at least
one key of each algorithm that is present in the DNSKEY RRset. It
followed the rules in section 2.2., RFC 4035. It was unclear that this
rule is for zone signing only, not for validating.

Therefor, Unbound has removed this check. It still checks the algorithms
signaled in the DS record. It only makes sense to me, because why would
you otherwise add the DS record of a different algorithm in the parent
zone? Even in the case of algorithm rollover you need to first add the
new DNSKEYs and sign and wait TTL.

This whole mandatory algorithms stuff is a moving target. Several
attempts were made to get this clear. From the current specification it
is unclear what validators may and cannot do. We should try to get
consensus about the clarifications, written down in dnssec-bis-updates.

Sorry for cross-posting.

Best regards,
  Matthijs