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 <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/ > 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
