* Astra mortemque praestare gradatim Does not apply to this thread, which goes in circles:)
* What does an RFC do here? This has been brought up on the thread multiple times. SW vendors tend to ship support for RFCs, not IANA code points or individual I-Ds. ________________________________ From: Watson Ladd <[email protected]> Sent: Tuesday, March 3, 2026 11:18 AM To: Andrei Popov <[email protected]> Cc: Thom Wiggers <[email protected]>; Loganaden Velvindron <[email protected]>; <[email protected]> <[email protected]> Subject: Re: [TLS] Re: [EXTERNAL] Re: Proposed Text on hybrid vs non-hybrid | Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27) Astra mortemque praestare gradatim On Tue, Mar 3, 2026, 11:13 AM Andrei Popov <[email protected]<mailto:[email protected]>> wrote: * NIST don’t mind hybrids. True, but my impression from past conversations with NIST (as well as multiple regulators around the world, albeit with some exceptions) is that they see hybrids (and composites) as a temporary/transitional solution at best, with the goal of getting to pure PQC. * There is also one particular set of purchasing requirements for US National Security systems (CNSA) that mandates pure PQC [1], where my impression [2] is strongly that this is not just to avoid “double migration” but perhaps even more so to simply reduce the number of algorithms they need to keep track of. Without speculating about CNSA’s motivation, it is true that if CNSA TLS profile (https://datatracker.ietf.org/doc/draft-becker-cnsa2-tls-profile/) were updated to add hybrid groups, there would be less immediate interest from MSFT side in advancing draft-ietf-tls-mlkem. Microsoft does not need the draft to advance to use the already allocated codepoints to interoperate with others with the same requirement. What does an RFC do here? Cheers, Andrei From: Thom Wiggers <[email protected]<mailto:[email protected]>> Sent: Tuesday, March 3, 2026 12:28 AM To: Loganaden Velvindron <[email protected]<mailto:[email protected]>> Cc: <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] [TLS] Re: Proposed Text on hybrid vs non-hybrid | Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27) Hi Loganaden, Op 3 mrt 2026, om 05:35 heeft Loganaden Velvindron <[email protected]<mailto:[email protected]>> het volgende geschreven: Alternatively, if NIST could support hybrids officially, a lot of the current issues would go away ? NIST don’t mind hybrids. It’s SDOs in e.g. Canada and the UK that are sending strong messaging that “double” migrations are potentially very costly and risky, and thus urge people to consider a direct-to-pure-PQ migration. There is also one particular set of purchasing requirements for US National Security systems (CNSA) that mandates pure PQC [1], where my impression [2] is strongly that this is not just to avoid “double migration” but perhaps even more so to simply reduce the number of algorithms they need to keep track of. People who mind hybrids mostly appear to do so for “soft” reasons rather than “hard” technical reasons. Arguing how practical/fast/small hybrids are, and that they shouldn’t mind them, isn’t really a convincing argument for them. Regards, Thom [1] CNSA 2.0 has one exception for when hybrids are absolutely necessary for compatibility reasons: my understanding is that this caveat exists basically just for IKEv2. [2] Clearly I’m not an American nor do I work for the NSA, so I can’t speak for them _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
