Speaking as someone who has often expressed the opinion that we don't need an RFC because the code points have been assigned, I think that it's a good thing to publish an RFC in this case.
More generally, I think the WG should publish a core set of specifications which represent our recommendations for best practices, while making it easy for others to register code points for other options. There seems to be fairly broad consensus that this specification is in the direction we recommend (it may be precisely what we want to recommend, but I'm leaving room to be wrong), so we ought to adopt it. -Ekr On Wed, Feb 26, 2025 at 11:45 AM 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
