John, Your understanding is probably correct, regarding what is required .
However, just like other entities often choose to follow the NIST standards, even though they are not “bound by their local law” to do so – I’m reasonably certain that many “non-NSS” US Government entities would follow CNSA-1.x and 2.x, regardless of whether it’s in their charter or not. And usually, an intersection between what NIST and NSA prescribe would be the safest bet. At least, it is for me. Unless one follows the belief – and I know people who do – that they all (NIST, NSA, whoever else “official”) are there to get you at all cost regardless of the negative impact it may have on their own security. -- V/R, Uri From: John Mattsson <[email protected]> Date: Sunday, November 9, 2025 at 11:26 To: Blumenthal, Uri - 0553 - MITLL <[email protected]>, Yaakov Stein <[email protected]>, [email protected] <[email protected]> Subject: [EXT] Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26) >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 ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside the Laboratory. ZjQcmQRYFpfptBannerEnd >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 <[email protected]> Sent: Sunday, November 9, 2025 6:14 PM To: Yaakov Stein <[email protected]>; [email protected] <[email protected]> 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 <[email protected]> Date: Sunday, November 9, 2025 at 03:00 To: David Adrian <[email protected]>, [email protected] <[email protected]> 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 <[email protected]> Sent: Thursday, November 6, 2025 1:46 AM To: [email protected] 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 < [email protected] <mailto:[email protected]> > 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] <mailto:[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] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
