> On 28 Feb 2024, at 09:58, John R Levine <jo...@taugh.com> wrote: > >>> The kind of load is different but in each case the client needs to >>> limit the amount of work it's willing to do. We can forbid it in the >>> protocol but unless you have better contacts at the Protocol Police >>> than I do, people will do it anyway. >> >> If you forbid in the protocol the tools will be fixed to prevent it >> occurring when signing and the validators don’t have to be prepared >> to play trial and error when there are duplicate tags in a DNSKEY >> RRset. ... > > That's all true, but people will publish them anyway, so the tools need to > defend against them no matter what the protocol says. Based on what I've > seen, pairs of colliding tags appear innocently, larger numbers don't, so you > set the limit in the single digits. > > Is it really so much harder to write code that allows, say, three signatures > and three IDs than code that only allows one? As I hardly need point out, > the process cost of changing the protocol is high, and it will take > approximately forever for the long tail to notice.
It’s not the complexity of the validator we are worried about. The number of crypto verifications per second is really low on all hardware. Being able to stop validating on the first failure rather than having to continue because the attacker has constructed a colliding key tag rrset is beneficial to getting good put trough in the presence of a DoS attack. As for the long tail we already have vendors that are doing what we are requesting to be formalised for years. Additionally this is in a component of the system that even if it isn’t updated in unlikely to generate DNSKEY rrsets with collisions. Most DNSKEY rrset don’t have more than 4 keys at any one time per algorithm. Also DNSSEC tooling is constantly being improved in terms of additional automation which encourages upgrades for anyone that is signing their zones. DNS server and with them the associated tooling do get upgraded regularly. We have the graphs to prove that. Upgrading software is a regular occurrence. I would put the time between publication of new signing rules and relying on them when validating at 2-3 years looking at the correction efforts that have already been done in the DNS in the past. > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
