[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[John Mattsson <[e-mail]>]

>US Government explicitly wants (a) pure ML-KEM, and (b) nothing less than ML-KEM-1024


Correct me if I am wrong, but I think the requirement for standalone ML-KEM-1024 applies for NSS (National Security Systems). My understanding is that it does not apply to all U.S. Government.


John


Sent from Commodore VIC-20
________________________________
From: Blumenthal, Uri - 0553 - MITLL <[e-mail]>
Sent: Sunday, November 9, 2025 6:14 PM
To: Yaakov Stein <ystein=[e-mail]>; [e-mail] <[e-mail]>
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

Based on what’s been posted and presented at various forums, US Government explicitly wants (a) pure ML-KEM, and (b) nothing less than ML-KEM-1024. They don’t forbid hybrids, but they do not want them – aka, if you’re selling a product to a US Government organization – hybrid is a liability, not a competitive advantage.

On the other hand, those who are the most vocal proponents of hybrids, en masse are happy enough with ML-KEM-768 (with something like X25519 or such).

So, it makes perfect sense for Chrome to provide hybridized ML-KEM-768 (addressing the needs of one audience), and pure ML-KEM-1024 (for a different, almost non-overlapping, audience).

My $0.05.
--
V/R,
Uri

From: Yaakov Stein <ystein=[e-mail]>
Date: Sunday, November 9, 2025 at 03:00
To: David Adrian <[e-mail]>, [e-mail] <[e-mail]>
Subject: [EXT] [TLS] Re: [EXTERNAL] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)
So, Chrome supports only pure MLKEM1024, while it supports the hybrid version with MLKEM768? Is that because you believe pure MLKEM768 to be too vulnerable and needs beefing up with X25519? Or is it a computational load issue with the hybrid
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.

ZjQcmQRYFpfptBannerEnd
So, Chrome supports only pure MLKEM1024, while it supports the hybrid version with MLKEM768?

Is that because you believe pure MLKEM768 to be too vulnerable and needs beefing up with X25519?
Or is it a computational load issue with the hybrid being about twice as expensive as MLKEM768 alone,
so with the pure mode you can afford the larger size which increases the load by about 50%?

Y(J)S

From: David Adrian <[e-mail]>
Sent: Thursday, November 6, 2025 1:46 AM
To: [e-mail]
Subject: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)


External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe
I support the publication of this document, and note that 0x0202 is implemented (behind a flag) in Chrome.

On Wed, Nov 5, 2025 at 1:52 PM Sean Turner via Datatracker <[e-mail]<mailto:[e-mail]>> 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 [e-mail]<mailto:[e-mail]>
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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you.