> Is the WG consensus to run four separate adoption calls for the individual > I-Ds in question?
I suggest to call for adoption of - draft-kwiatkowski-tls-ecdhe-mlkem - draft-tls-westerbaan-mldsa - draft-reddy-tls-composite-mldsa - draft-reddy-tls-slhdsa Personally, I don't think all of those should be adopted, but I will share that when there is an adoption call. I also think that - draft-connolly-tls-mlkem-key-agreement/ can wait for a couple of years. It already has codepoints, so it can be used by early adopters that need it. -----Original Message----- From: Sean Turner <s...@sn3rd.com> Sent: Monday, December 16, 2024 5:00 PM To: TLS List <tls@ietf.org> Subject: [EXTERNAL] [TLS] PQ Cipher Suite I-Ds: adopt or not? CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. 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 -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
