On Tue, Mar 3, 2026, 12:58 PM Andrei Popov <[email protected]> wrote:
> > - Astra mortemque praestare gradatim > > Does not apply to this thread, which goes in circles:) > someday Gmail will work the way it used to :p > > > - 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. > Are you saying that this applies to you and you cannot ship support absent an RFC? It seems odd to talk about the reluctance of third parties to implement something in talking about the interest you have in the draft. > ------------------------------ > *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 <Andrei.Popov= > [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]> > *Sent:* Tuesday, March 3, 2026 12:28 AM > *To:* Loganaden Velvindron <[email protected]> > *Cc:* <[email protected]> <[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]> > 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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
