On 11/27/2013 10:24 PM, Peter Koch wrote:
> 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.
http://tools.ietf.org/html/rfc6840#section-5.11
I believe the general consensus was that the liberal approach is what
was actually meant. That is why RFC 6840 clarifies them. But because
there was confusion in the past, RFC 6781 (DNSSEC Operational Practices,
v2) also mentions the conservative approach. We don't have good
estimates of how many validators are strict in this sense. If you want
to make sure that your zone does not go bogus anywhere during an
algorithm rollover, it is best to follow the conservative approach.
I think it would be wise that all signing solutions follow the
conservative approach.
Best regards,
Matthijs
>> 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
>
_______________________________________________
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
