> On Feb 26, 2025, at 3:03 PM, David Benjamin <david...@chromium.org> wrote: > > 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".
Yeah, I get it, I’m just not particularly persuaded by the value of that signal as something meaningful. In any case, I didn’t mean to distract the thread with philosophical procedural questions, especially when my distraction was literally expressing concern that this working group might possibly be distracted 🤣 And just in case it was not clear: I support adoption. > 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. :-) Definitely. Maybe we can adopt before Bangkok and then start WGLC immediately after. =) Best, Chris > > David > > On Wed, Feb 26, 2025 at 2:45 PM Christopher Wood <c...@heapingbits.net > <mailto: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 >>> <mailto: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 <mailto:tls@ietf.org> >>> To unsubscribe send an email to tls-le...@ietf.org >>> <mailto:tls-le...@ietf.org> >> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org> >> To unsubscribe send an email to tls-le...@ietf.org >> <mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
