I've definitely had folks ask whether it's OK to deploy this yet, so I think it would be valuable. I can't really fault them for asking---the usual story is that draft things are doomed to be replaced by their final standards and this one hasn't even been adopted. Really, I'm appreciative that those folks have taken the lesson to heart! For the sake of other IETF work, where WGs _do_ need to iterate, I would much rather that we keep the heuristic clear. Otherwise we'd have to muddy the waters and say "well, yes, this is normally the case, but just this once the WG was kinda busy, but I promise this one is also stable, really."
In particular, even though the codepoint's meaning is now fixed, publishing it sends a clear signal that this is the WG-blessed spelling of an ECDHE/ML-KEM hybrid for TLS, and that adopters are not dramatically at risk of the ecosystem deciding "no, actually we're going to retire this one and transition to a different codepoint that paints the bikeshed differently". Being concerned about the WG's time makes sense, but given that this is a case where the WG has gotten very very behind running code, hopefully we can try to stamp this one with minimal fuss and time spent. After all, we've already been debating the finer points of this one since before this document existed. To that end, I would suggest that we all try to progress this document quickly. :-) David On Wed, Feb 26, 2025 at 2:45 PM Christopher Wood <c...@heapingbits.net> wrote: > As I understand it, the purpose of this draft is to specify an > interoperable key exchange mechanism that we can deploy. The draft already > has code points allocated to it, and they exist in the registry > <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8>, > so I wonder: what is the point of adopting this draft when the important > work is already done? If it’s that some folks won’t implement it until > there’s an RFC number assigned to it, well, that’s pretty silly. I support > adoption if it helps this work get implemented more broadly, but I think > it’s worth asking whether or not this is a good use of an already busy > working group’s time. > > Best, > Chris > > On Feb 26, 2025, at 1:26 PM, Sean Turner <s...@sn3rd.com> wrote: > > At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key > Agreement for TLSv1.3”; see [0] and [1]. We also had some discussion in an > information gathering thread; see [2]. We would like to now determine > whether there is support to adopt this I-D. If you support adoption and are > willing to review and contribute text, please send a message to the list. > If you do not support adoption of this I-D, please send a message to the > list and indicate why. This WG adoption call will close at 2359 UTC on 12 > March 2025. > > One special note: this adoption call has nothing to do with picking the > mandatory-to-implement cipher suites in TLS. > > Thanks, > Sean & Joe > > [0] Link to I-D: > https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/ > [1] Link to slides: > https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00 > [2] Link to information gather thread: > https://mailarchive.ietf.org/arch/msg/tls/yGZV5dBTcxHJhG-JtfaP6beTd68/ > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
