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 the
> 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
> writers.
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" interpretation
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
> (resolving 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 entity
to verify that the MUST has been followed. The robustness principle explicitly
does not preclude this. ("Mum, the other boy has been hitting back first!")
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@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
