On Mon, Dec 16, 2024 at 2:01 PM Sean Turner <s...@sn3rd.com> 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/
I'd like to see adoption calls particularly for the second one of these. > 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/ I think these are less urgent but why wouldn't we have a call? Nonadoption now doesn't preclude adoption in the future. > > 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/. Do they expect work to stop in the meantime on this? Honestly CFRG workload and structure is the big problem that needs addressing, not TLS dealing or not with these. Anyway, this seems to drift from the very clear question asked. > > * 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. Why wouldn't one of the hybrids get recommended Y, even if the pure didn't? > > * 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. I wouldn't equate these two. No reason a me (or someone else) with much free time couldn't write a draft to update this outside of the bis. > > * 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? I think we should. > > The Chairs, > Deirdre, Joe, and Sean > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
