[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[Benjamin Kaduk <[e-mail]>]

I think that Nico is right to identify that at its core the question for the WG
is one of policy, and Dan is right to look to the WG charter for guidance.

I see two parts of the charter that could cover this work -- "[t]his goal also
includes protocol changes that reduce TLS resource consumption without
affecting security", and "[t]he second working group goal is to improve
security, privacy, and deployability."  It is a little hard to argue that this
work reduces resource consumption without affecting security, which seems to be
a core theme in Dan's objection to adoption.  But the charter is silent about
the deployability goal other than the exerpt I quote, which leaves a fair bit
of room for interpretation of this work as being included in that part of the
charter.

I can see a case being made that this draft does improve the deployability of
TLS if we start with a baseline of draft-ietf-tls-ecdhe-mlkem and note that
that mechanism is not deployable in some environments (I guess, ones with some
kind of strict FIPS-only requirement, though I'm not conversant in the details
of such an environment).  Dropping the ECDHE does then make the scheme more
deployable at the cost of some risk to the security guarantees, and the
magnitude of that risk is hard for me to assess.  This line of argument also
seems to address another one of Dan's concerns about having a way to draw the
line between this algorithm and other national algorithms, especially in the
context of the WG having been trying to push "national crypto" to the ISE in
general.  If we do have a WG-recommended scheme that is not deployable in some
environments, we do have the freedom (but not the obligation) to adopt and
document a variation of that recommended algorithm that is "more deployable",
but that does not give us freedom to adopt arbitrary national crypto algorithms
unless they are part of a WG-recommended construction that has deployability
concerns that we choose to care about.

WG adoption also gives us a very strong level of control over the text
accompanying the protocol specification itself, including the security
considerations, deployment guidance, and recommendations for (non-)use.  So
even if I would not use pure MLKEM myself and would recommend that others not
do so as well, I can still see adopting this document as being better than
having it published via ISE in that it gives us a good way to write up the
caveats and risks around its use (and a chance to prohibit key reuse).  Dan has
argued (if I understand correctly) that we should not accept letting it get
published via ISE either, but I think that is pretty hard to justify given that
we have actively pushed other crypto algorithms to publish via ISE, even when
we think they are bad in some sense.  So if the choice is between publishing as
WG document with strong caveats and disclaimer that hybrids should be preferred
if they are deployable, and publishing via ISE without such caveats, I would
pick the WG-document version.  Whether I (or anyone else) would prefer not
having the TLS SupportedGroups codepoints 512-514 defined at all or not is
simply not relevant, as that is no longer a possibility.

-Ben

On Mon, Apr 14, 2025 at 12:02:15AM -0400, Sean Turner wrote:
> !-------------------------------------------------------------------|
>   This Message Is From an External Sender
>   This message came from outside your organization.
> |-------------------------------------------------------------------!
> 
> Just a reminder that this WG adoption call closes tomorrow.
> 
> Cheers,
> spt
> 
> > On Apr 1, 2025, at 8:58 AM, Sean Turner <[e-mail]> wrote:
> > 
> > We are continuing with our pre-announced tranche of WG adoption calls; see [0] for more information. This time we are issuing a WG adoption call for the ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D [1]. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this draft, please send a message to the list and indicate why. This call will close at 2359 UTC on 15 April 2025.
> > 
> > In response to other WG adoption calls, Dan Bernstein pointed out some potential IPR (see [2]), but no IPR disclosure has been made in accordance with BCP 79.  Additional information is provided here; see [3].
> > 
> > BCP 79 makes this important point:
> > 
> >  (b) The IETF, following normal processes, can decide to use
> >    technology for which IPR disclosures have been made if it decides
> >    that such a use is warranted.
> > 
> > WG members can take this information into account during this adoption call to determine if we should adopt these drafts.
> > 
> > Reminder:  This call for adoption has nothing to do with picking the mandatory-to-implement cipher suites in TLS.
> > 
> > Cheers,
> > Joe and Sean
> > 
> > [0] https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/__;!!GjvTz_vk!SUUSF07W5ceLD8t-9ebVDShWKxztuYGUUWu-tzNJAuZErxDMARrWEAxLBBBtY4b-MNxV0NSIQQ$ 
> > [1] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/__;!!GjvTz_vk!SUUSF07W5ceLD8t-9ebVDShWKxztuYGUUWu-tzNJAuZErxDMARrWEAxLBBBtY4b-MNyYj2GOUg$ 
> > [2] https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/__;!!GjvTz_vk!SUUSF07W5ceLD8t-9ebVDShWKxztuYGUUWu-tzNJAuZErxDMARrWEAxLBBBtY4b-MNzSNkIZ2Q$ 
> > [3] https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/__;!!GjvTz_vk!SUUSF07W5ceLD8t-9ebVDShWKxztuYGUUWu-tzNJAuZErxDMARrWEAxLBBBtY4b-MNwvr-gAnQ$ 
> > 
> 
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]