In message <20131127221711.9f444ae4...@rock.dv.isc.org>, Mark Andrews writes:
>
> In message <20131127212453.gb5...@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@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: ma...@isc.org
> _______________________________________________
> dns-operations mailing list
> dns-operations@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: ma...@isc.org
_______________________________________________
dns-operations mailing list
dns-operations@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
