Moin! On 15 Feb 2024, at 11:17, Paul Wouters wrote: > Resolvers would have disabled dnssec to remain alive.
So you are saying we should disable security features when under attack? Should we have disabled http/2 when the rapid reset attack came around? Sorry but I don’t think that is sound advice, and it also would have take some time to figure that out. > Also not at all something nice to happen, but the Internet in fact would not > have died. The whole Internet not, large portions of it yes. I don’t think people not involved have grasped the severity of the KeyTrap vulnerability, but maybe this will sink in once people read and understood the paper. I still remember my pale face when they showed us what a single packet could do. This was the worst DNS vulnerability since Kaminsky 2008 and it attacked the mechanism we decided to use to defend against Kaminsky (DNSSEC). > The IETF isn't the protocol police. It does not do "flag days" although > the DNS community has certainly run a few events like that (all of which > I opposed other than the EDNS0 workaround issue). While there is a good > use case for flag days for cutting of a long tail of RFC violating legacy, > eg like cutting EDNS0 workarounds after 20 years, there has not yet been > an RFC stating that keytags are not allowed to be duplicate. As such, > a flag day is not appropriate. If you publish an RFC, then wait 20 years, > then a flag day could be appropriate. Of course, that's just the view of > the IETF that does not do flag days. Hmm I thought if we publish an RFC that updates the DNSSEC RFCs to not allow keytag collisions I could change my resolver tomorrow and be RFC compliant. There is no need to wait 20 years or did I miss something? So long -Ralf ——- Ralf Weber _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
