If web browsers can provide both x25519mlkem768 (and maybe x25519mlkem1024 at a later time ?) and mlkem1024 for satisfy both demands, I think it's a good way for us to move forward.
That’s been the consensus for quite some time, as far as I recall. (Except for a few dissenters who absolutely can’t accept that somebody else may use pure mlkem1024.) If we can agree to support both hybrid and pure, then I'm OK with supporting the I-D to satisfy those compliance requirements for the US government. I think this is the status quo, and the majority (at least, the way I read this WG) is not planning to change it. On Wed, 5 Nov 2025 at 23:04, Stephen Farrell <[email protected]> wrote: > > > I re-read the document. It has zero commentary on the issues about > hybrids vs. pure PQ. It may be hard to reach rough consensus on what > to say about that, but it is a topic where people have significantly > different opinions, so I think we ought say something, for example, > along the lines of, "At the time of writing a significant number of > knowledgeable people consider it better to deploy hybrid KEMS, while > some do dispute that. Opinions may change over time." I'd be happy > but surprised if the WG had consensus to add such text, but we > should. Absent that, I think producing an RFC based on this draft > provides a misleading signal to the community. > > Also - what happened to the adopt-but-park plan? Did that get lost > in the fog of appeals? > > Cheers, > S. > > On 05/11/2025 18:51, Sean Turner via Datatracker wrote: > > > > Subject: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26) > > > > This message starts a 3-week WG Last Call for this document. > > > > Abstract: > > This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as > > NamedGroups and and registers IANA values in the TLS Supported Groups > > registry for use in TLS 1.3 to achieve post-quantum (PQ) key > > establishment. > > > > File can be retrieved from: > > https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ > > <https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/> > > > > Please review and indicate your support or objection to proceed with the > > publication of this document by replying to this email keeping [email protected] > > in copy. Objections should be motivated and suggestions to resolve them are > > highly appreciated. > > > > Authors, and WG participants in general, are reminded again of the > > Intellectual Property Rights (IPR) disclosure obligations described in BCP > > 79 > > [1]. Appropriate IPR disclosures required for full conformance with the > > provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of > > any. Sanctions available for application to violators of IETF IPR Policy can > > be found at [3]. > > > > Thank you. > > > > [1] https://datatracker.ietf.org/doc/bcp78/ > > <https://datatracker.ietf.org/doc/bcp78/> > > [2] https://datatracker.ietf.org/doc/bcp79/ > > <https://datatracker.ietf.org/doc/bcp79/> > > [3] https://datatracker.ietf.org/doc/rfc6701/ > > <https://datatracker.ietf.org/doc/rfc6701/> > > > > > > > > _______________________________________________ > > TLS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
