[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

[Eric Rescorla <[e-mail]>]

I think we should do an adoption call for:
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/

Key establishment is the most urgent need and I think the WG has a clear
appreciation of the implication of adopting these drafts, so it's ripe for
a call for adoption. I'm much less enthusiastic about the pure ML-KEM
draft than I am about the hybrid draft, but I think a call for adoption is
the appropriate way for the WG to make the decision about whether to
adopt both drafts or just one.

I think we should hold off on the signature drafts for a while longer, both
to
allow the WG to prioritize key establishment and to make some space
for thinking about the right direction.

-Ekr


On Mon, Dec 16, 2024 at 2:00 PM Sean Turner <[e-mail]> wrote:

> Note that there are three parts to this email; the “ask” is at the end.
>
> Requests:
>
> Ciphersuite discussions in this WG often turn nasty, so we would like to
> remind everyone to keep it civil while we explain our thinking WRT recent
> requests for WG adoptions of some PQ-related I-Ds.
>
> Also, the chairs are trying to gather information here, not actually do
> the calls. If we decide to do them we will do them in the new year.
>
> Background:
>
> Currently, the TLS WG has adopted one I-D related to PQ:
> Hybrid key exchange in TLS 1.3;
>   see https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
> This I-D provides a construction for hybrid key exchange in the TLS 1.3.
> The I-D has completed WG last call and is about to progress to IETF LC.
>
> There are a number of Individual I-Ds that specify PQ cipher suite for TLS
> currently being developed that specify either “pure” PQ or composite/hybrid:
>
> ML-KEM Post-Quantum Key Agreement for TLS 1.3;
>   see
> https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
> PQ hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,
>   see https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
> Use of Composite ML-DSA in TLS 1.3;
>   see https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
> Use of SLH-DSA in TLS 1.3;
>   see https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
>
> The IANA requests for code points in the I-Ds (now) all have the same
> setting for the “Recommended” column; namely, they request that the
> Recommended column be set to “N”. As a reminder (from RFC 8447bis), “N”:
>
>       Indicates that the item has not been evaluated by the IETF and
>       that the IETF has made no statement about the suitability of the
>       associated mechanism.  This does not necessarily mean that the
>       mechanism is flawed, only that no consensus exists.  The IETF
>       might have consensus to leave  items marked as "N" on the basis
>       of it having limited applicability or usage constraints.
>
> With an “N”, the authors are free to request code points from IANA without
> working group adoption. Currently, five code points have been assigned; 3
> for ML-KEM and 2 for ECDHE-MLKEM.
>
> While there have been calls to run WG adoption calls for these I-Ds, the
> WG chairs have purposely NOT done so. The WG consensus, as we understand
> it, is that because the IANA rules permit registrations in the
> Specification Required with an I-D that there has been no need to burden
> the WG; there is, obviously, still some burden because the I-Ds are
> discussed on-list (and yes there have been some complaints about the volume
> of messages about these cipher suites).
>
> There are a couple of other reasons:
>
> * The ADs are formulating a plan for cipher suites; see
> https://datatracker.ietf.org/doc/draft-pwouters-crypto-current-practices/.
>
> * There are a lot of different opinions and that likely leads to a lack of
> consensus. Based on discussions at and since Brisbane, we do not think
> there will be consensus to mark these ciphersuites as "Y" at this point,
> however the working group can take action to do so in the future.
>
> * There have been a few calls to change the MTI (Mandatory to Implement)
> algorithms in TLS, but in July 2024 at IETF 120 the WG consensus was that
> draft-ietf-tls-rfc8446bis would not be modified to add an additional
> ciphersuite because the update was for clarifications.
>
> * Adopting these or some subset of these I-Ds, will inevitably result in
> others requesting code points too. The WG has historically not been good
> about progressing cipher suite related I-Ds, either the discussion rapidly
> turns unproductive or interest wanes during the final stages in the
> publication process. So while there is great interest (based on the number
> of messages to the list) about these I-Ds, we are unsure how to avoid the
> inevitable complaints that would follow failure to adopt or not adopt a
> specific I-D based on different requirements of different individuals.We
> know some of you are thinking that that’s “tough”, but if we do not need to
> have this fight, see the previous paragraph, we do not see the harm in
> avoiding these complaints.
>
> The chairs would also like to note that currently the WG consensus is to
> NOT port PQ cipher suites back to (D)TLS 1.2.
>
> Ask:
>
> Is the WG consensus to run four separate adoption calls for the individual
> I-Ds in question?
>
> The Chairs,
> Deirdre, Joe, and Sean
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>