> As I have stated during the life of this document, I do not think > it is a useful document as the envisioned lifecycles so far seem > to have all been changed due to unexpected events (sha1 breakage, > new dos attacks, etc) and having a theoretical lifecycle of dont > break things seems so obvious it doesnt need writing down and the > specific actions will always have to be taken after discussion > through the WG via Standards Track actions anyway in response to > specific events.
In my opinion this is an important document. During the discussion about allowing multi-signers to use different algorithms it became clear that a lifecycle document is needed. SHA1 breakage can hardly be called an unexpected event when DNSSEC is concerned. First, SHA1 was assumed to be broken long before the first pulbic attack. However, SHA1 is broken where attackers can create collisions. For most of DNSSEC that is not problem. As far as I know, people have described how to abuse SHA1 collisions in theory, but nobody has done so in practice. The main SHA1 breakage came from a vendor who decided to release an OS that just broke RSASHA1. Making RSASHA1 unsupported might just be annoying for people who need DNSSEC validation to work, for example for DANE. But letting RSASHA1 become bogus is very bad. However, the IETF cannot do anything about vendors releasing broken software for weird reasons, so that should not stop us from setting policies. With upcoming PQC algorithms, it will be good to have a clear policy on how to introduce and retire algorithms. And if the lifecycle of algorithms is obvious, then it should not take much time to get consensus and be done. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
