[dns-operations] algorithm rollover strategies

[Matthijs Mekking]

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 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
>