Hi all, I don't normally post on the TLS mailing list, but there's enough, shall we say, drama happening here that I thought my opinion worthwhile.
I support publication of this draft as an RFC. I'm not going to engage with the political arguments made here by many. Quite simply, I don't have the energy for more politics in my life right now. I instead think that this document should be considered from the perspective of what the IETF is and does. The IETF is not a regulatory body, the IETF does not police how people use the Internet (in spite of what RFC 8962 <https://www.rfc-editor.org/rfc/rfc8962.html> may suggest 😁). The IETF is a place for us, as a community, to publish standards so that we all can agree on how to talk to each other over the Internet, however we want. That a document is published as an RFC is not a requirement to use it, or even an endorsement of it. Anyone is perfectly free to look at an IETF standard, conclude it is awful, and not implement it. Equally, there are evidently people who *do* want to pure ML-KEM key agreement in TLS, so we better standardise how that's done before we end up with a mess of incompatible implementations. It is not our job in this case to judge if using pure ML-KEM or a hybrid is a good idea or not, and the document explicitly states this, by stating it is not an IETF recommended algorithm. Consequently, we are not here to judge if the algorithm is a good idea, but merely if standardisation is warranted to avoid implementation fragmentation. In this case, it is almost trivial to conclude that it is worthwhile. Q
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
