-1. Strongly.
I think that having DNSSEC non-BOGUS 100% of the time is critical at
least for important zones (like TLDs). This includes protecting about
things that may go wrong, even when they did not yet go wrong in the past.
AFAIK the current state is that the _specification_ allows the
atuhoritatives to publish DNSKEYs with any number of konflicting keytags
and the validating resolvers MUST(?) accept those; while in _reality_
the resolvers started to impose some limitations. This dicrepancy
between specification and reality should be fixed by us.
There have even been some incentive by a validating resolver vendor to
outlaw keytag conflicts completely. We should bring a clear
specification which clearly states the maximal amount of keytag
conflict. Both for the authoritatives to know where is the limit _and_
for the resolvers to be required to accept those.
I suggest something like: "resolvers MUST accept two keytag-conflicting
keys within *each* DNSKEY RRset they are validating" and "authoritatives
MAY publish DNSKEY with at most two keytag-conflicting keys" and
"authoritatives SHOULD do best effort to avoid keytag conflicts whenever
possible".
Libor
On 08. 07. 25 8:49, Peter Thomassen wrote:
On 7/8/25 02:17, John Levine wrote:
It appears that Shumon Huque <[email protected]> said:
Please review the draft and speak up if you have comments, and would
like
to see this draft adopted (or not).
I don't hate the draft but since we have been living with colliding
tags for two
decades and experience shows that collisions of more than two tags
never appear
unless maliciously created, this doesn't strike me as a good use of
our time.
Just add "more than two colliding tags" to the long list of limits in
DNS
resolvers and we can work on something else.
+1
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
