On Tue, Dec 24, 2024 at 10:55 AM Eric Rescorla <e...@rtfm.com> wrote:
> I think we should do an adoption call for: > https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ > Oops. I meant: https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/ > 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
