[dns-operations] algorithm rollover strategies

[Mark Andrews]

In message <20131127221711.9F444AE4AEB at rock.dv.isc.org>, Mark Andrews writes:
> 
> 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 th
> at
> >  were
> > > not in line with the apparently incompletely stated intent of the rule wr
> it
> > 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" interpretat
> io
> > 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 "zon
> e 
> > signing"
> > > and 2.2 was in "including RRSIGs in a zone" and not in sections 4 or 5 (r
> es
> > 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 e
> nt
> > ity
> > to verify that the MUST has been followed. The robustness principle explici
> tl
> > 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.

     If the response is to be cached for other validators then
     RRSIGs for all algorithms SHOULD be present as stripped RRSIG
     records represents a denial of service threat to the down
     stream validator.

> 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 Righ
> t 
> > 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
> _______________________________________________
> 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