[dns-operations] algorithm rollover strategies

[Mark Andrews]

In message <20131127212453.GB5690 at x28.adm.denic.de>, Peter Koch writes:
> On Wed, Nov 27, 2013 at 08:48:05AM -0500, Edward Lewis wrote:
> 
> > It should be:
> > 
> > There MUST be an RRSIG for each RRset using at least one DNSKEY of
> > each algorithm in the zone apex DNSKEY RRset that is also in the DS RRset. 
>  The apex DNSKEY RRset
> > itself MUST be signed by each algorithm appearing in the DS RRset
> > located at the delegating parent (if any).
> 
> I disagree.  If you go down that path, the signing should be independent
> of data present elsewhere, i.e., the description should not depend on
> a DS RRSet being present, absent, complete, or incomplete.
> 
> > The latter is what I thought had been written until I re-read the section a
>  few weeks ago.
> > 
> > It's too late to go back and change implementations that interpreted even t
> he
> > as-is text incorrectly.  By "wrong" I mean interpretations of the rule that
>  were
> > not in line with the apparently incompletely stated intent of the rule writ
> ers.
> 
> In all fairness, the issue escaped not only the writers but also everybody
> who reviewed the document, including some of us here in this thread.
> On the other hand, it has been argued that the "all algorithms" interpretatio
> n
> was indeed intended to mitigate downgrade attacks.
> 
> > In the rear view mirror I can see how a validator might take the above as a
> > requirement, but it means that they didn't notice that section 2 was "zone 
> signing"
> > and 2.2 was in "including RRSIGs in a zone" and not in sections 4 or 5 (res
> olving and validating).
> 
> Well, while that makes sense in part, see above, if there's a MUST on the
> side that describes the zone/response content, it is OK for the consuming ent
> ity
> to verify that the MUST has been followed. The robustness principle explicitl
> y
> does not preclude this. ("Mum, the other boy has been hitting back first!")
 
Firstly there a plenty of cases when MUST on the sender side are
not to be checked on the receive side in lots of protocols.  Asymetric
behaviour is not uncommon.

Secondly it is MUST for a *instance* of the zone.  The validator
is not, in general, in a position to determine if the response to
the DNSKEY query comes from the same instance of the zone that the
covering RRSIGs are from.

If it wasn't a MUST for a instance of a zone then we would have had
words like.  You MUST publish signatures <amount of time> before you
introduce a DNSKEY algorithm.

Unbound just got it WRONG and should issue a notice to upgrade all
instances that contain this bug.

If we want to be able to protect from stripped signatures then the
list of algorithms used to sign the zone needs to be in the RRSIG
and be included in the data hash that is signed.  We know how to
introduce this change in behaviour if we want to.  Something like

   If the algorithm is greater than x and not ... then the
   list of dnssec algorithms used to sign the zone along with
   a length octet is included at the start of the signature.
   This list is included the hash that is signed.

   A validator MAY check a response to see if all the algoritms
   listed in any RRSIG are includes in the response and MAY reject
   the response if they are not found.

One can then decide if one wants to introduce alias for some of the
existing algorithms or not.

Mark

> I would have thought that the previous instance(s) of this discussion had
> been preserverd somewhere, but I could not find an erratum against 4035.
> That's probably due to the fact that there was no consensus w.r.t. the Right 
> Way.
> 
> > So - I wish we could measure the impact of what has been deployed.
> 
> -Peter
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org