[TLS] Re: [EXTERNAL] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Mike Ounsworth <[e-mail]>]

I second Rob and David. RFC numbers matter outside the IETF; they are a signal that something is mature and well-vetted, and can then be re-ratified in NIST documents, ISO documents, PCI documents, etc etc. 

 

I think that for something as critical as the recommended PQ TLS cipher suite, saying “It’s documented in an expired unadopted draft” is setting a bad precedent.

 

Since the technical details are immutable at this point, and the only thing for the WG to do is massage the prose, I think this can fly through to WGLC pretty quickly. 

 

I am willing to review and help iterate the descriptive text.

 

---

Mike Ounsworth

 

From: Rob Sayre <[e-mail]> 
Sent: Wednesday, February 26, 2025 2:19 PM
To: Christopher Wood <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] [TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

 

On Wed, Feb 26, 2025 at 11: 43 AM Christopher Wood <caw@ 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



On Wed, Feb 26, 2025 at 11:43 AM Christopher Wood <[e-mail] <mailto:[e-mail]> > 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://urldefense.com/v3/__https:/www.iana.org/assignments/tls-parameters/tls-parameters.xhtml*tls-parameters-8__;Iw!!FJ-Y8qCqXTj2!caxA5xKNO9EN5tBE2pwtNVuOlDf3jQuTmziPO0IkHs2TkjXL0eNzCImowcnqd_JJQae-2acySqI9hNe2Yis$> , 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.

 

It is silly. But the nature of the issue is that people that do implement it can put "RFC NNNN support" on their comparison checklists. So, it's more effective than the code points, especially if we want to encourage smaller implementations to implement.

 

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.

 

 I think it will help the work get implemented more broadly, so I support adoption.

 

thanks,

Rob