Hi All, I am also concerned regarding those issues raised. While I understand that compliance mandates pure MLKEM1024 for some government, I still prefer x25519mlkem768 or even x25519mlkem1024 as a safer bet for general adoption.
Like we saw with "Kyberslash",There are implementation issues that can happen. I would prefer to see some discussion in the draft so that developers are at least aware of those issues. 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. 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. 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/ > > > > 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/ > > [2] https://datatracker.ietf.org/doc/bcp79/ > > [3] 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]
