That's a lot of questions. I'd actually prefer to keep this simple for now: just mark the algorithms in draft-ietf-ecdhe-mlkem Y and leave the other questions for later.
-Ekr On Mon, Feb 23, 2026 at 6:19 AM Bas Westerbaan <bas= [email protected]> wrote: > Hey all, > > Given store-now/decrypt-later, we should update our recommendations. > > I've drafted a quick I-D which we could work on. I couldn't help myself to > have my preferred outcome as a stub, but it's just a starting point. > > > https://datatracker.ietf.org/doc/draft-westerbaan-tls-keyshare-recommendations/ > > Now, to actually make progress I see the following questions (if we desire > to work on this): > > 1. Do we want to keep "Y" for quantum vulnerable algorithms? This is > probably an easy one. > > 2. Bit harder: do we discourage ("D") or stay neutral ("N") on quantum > vulnerable algorithms? Recall that "N" is defined as > > 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 an > item marked as "N" on the basis of the item having limited applicability or > usage constraints. > > > Personally I prefer D, but I can live with N if we add a comment. > > 3. Which post-quantum key shares do we want to recommend? There is an > obvious trade off between fragmentation and hindering use cases. > > 3a. X25519MLKEM768. Uncontested in adoption at the moment. > > 3b. SecP384MLKEM1024. Higher number. Do note that we recommended P384 (at > the same classical level as MLKEM768) but not P521. > > 3c. SecP256MLKEM768. Does it add value next to X25519MLKEM768? There are > arguments about what FIPS modules or hardware is available today. Is that > worth a recommendation? > > 3d. curveSM2MLKEM768. We did not recommend curveSM2. > > 3e. MLKEM{512,768,1024}. Let me cop out here and say we should consider > this once we actually first adopt a document for it. > > My preference is to stick with X25519MLKEM768 for now. > > Thoughts? > > Best, > > Bas > > > > > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
