Given all the unnecessary strife the fact that X25519MLKEM768 is Recommended = N has caused, I would definitely vote for changing that to Y. I think independently of that, we should start an effort of moving classical only algorithms to N or D. D might sound aggressive now, but note that e.g. NIST has already marked them as deprecated by 2030. Given how long IETF takes to debate these things, maybe we should start with D already, then we might be ready on time 😬.
On Tue, Feb 24, 2026 at 7:36 AM Nick Sullivan <[email protected]> wrote: > Two questions should be asked when deciding whether to add a code point to > recommended=Y in this IANA registry: > (1) Does the primitive provide the expected security properties in the > context of TLS? > (2) Is the group comfortable with the downstream consequences of adding > the recommended codepoint? > > > For (1), there are well-worn paths for a WG to get expert feedback and > build confidence. > > A. Security properties of the primitive itself: > - Reference a CFRG document (published or adopted) that specifies the > primitive and has a convincing Crypto Panel review > - Reference an externally specified primitive from an open process, where > either: > -> there is a CFRG security considerations document (with a convincing > Crypto Panel review) or > -> the TLS chairs solicit a Crypto Panel review of the external document > from the CFRG chairs and find it sufficient > B. Security properties of the TLS integration: > - FATT can provide useful feedback on the protocol-level integration into > TLS. > > > How does this apply to this draft? > The MLKEM768 primitive hasn't been looked at directly by the CFRG, but > there is an individual draft that provides some confidence that it is > secure in the TLS context: > > https://datatracker.ietf.org/doc/draft-sfluhrer-cfrg-ml-kem-security-considerations/ > > The CFRG chairs (sneak peek) are presently considering opening up the > topic of PQ-KEM security considerations for adoption. The expectation is > that if WGs are interested in standardizing PQ-KEMs for their protocols > (ML-KEM or others, please make it a short list), the CFRG could adopt a > slate of documents that analyze the use of each primitive in the IETF > protocol context. Each document would eventually undergo a crypto panel > review. (this satisfies "there is a CFRG security considerations document") > > > If CFRG adopts this topic or the TLS chairs solicit a Crypto Panel review, > and the WG is comfortable with the resulting security claims, I'm all for > answering 'yes' to question (1). > > Question 2), on the other hand, deserves a separate conversation. > > Nick > > On Mon, Feb 23, 2026 at 9: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] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
