Peter Thomassen <[email protected]> writes: > We've been living this approach already, both slowly (with > introduction of EC algorithms, close to what the ideal transition > would have been) and quickly (SHA-1 phase-out).
There are no protocol police, so no bad decisions can be mitigated by having a document. I'm sure that's one thing we all do agree upon, and there are many many many examples of intentional and accidental breaking of various protocols over time. Some by forced extensions that are incompatible with the rest of the world for lock-in purposes, etc. > I therefore have difficulty seeing what this document would change in > practice; I'm also not convinced the document would have prevented > RedHat from prematurely turning off SHA-1 support in their OS release, > had it existed at the time. It would be informational, to me, to have a document where we had the discussion of what the right path steps and timing was, got IETF agreement on it, so we could use it when making new documents like RFC9905 (deprecating SHA1) and RFC9906 (deprecating GOST) so we would have our own agreed up guidance to at least consider and hopefully follow. It will not prevent the need to jump multiple steps forward in emergencies or other cases. But it gives us a solid set of guidance to at least try to follow. Implementations and deployments will still force our hands at times. -- Wes Hardaker Google _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
