My point was really that it is not all or none. We could do as some has suggested doing some subset.
spt Sent from my iPhone > On Dec 16, 2024, at 18:47, Watson Ladd <watsonbl...@gmail.com> wrote: > > 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
