Hello TLS WG and chairs, I'd like to propose a renewal for the call for adoption of pure-mlkem ( https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/) as an RFC out of the TLS WG.
This seems to move beyond Joe's recent comments here that the current intent is to run a specific consensus call on the changed text (regarding, by my understanding, the Motivation & Security Consideration sections of https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/). Accordingly, further context and explanation is needed for this message than a simple in-line reply. Many years ago, I was NIST's lattice cryptographer during the (now) decade-long process of standardizing ML-KEM. I apologize for my late arrival. I've watched the steps within the TLS working group from afar. Admittedly, I have not been an active participant in the draft process for pure-mlkem in IETF's TLS WG to this point. In terms of understanding the way in which IETF works, I refer to RFC 7282, https://datatracker.ietf.org/doc/html/rfc7282. I'm approaching this discussion from that document, plus what I've seen in the TLS WG mailing list discussion. In the sense of RFC 7282, my previous position has been one of preemptive capitulation. In other words, "Forget it; do what you want." In the words of RFC 7282, this simply means "That's not coming to consensus; there still exists an outstanding unaddressed objection." To wit, I notice that the first session of the TLS WG at IETF 125 began with a recounting of a mailing list ban of DJB, and an first-item-issue in the WG of an apology by the chairs to DJB of accidentally censoring a message of his. Having spent much time on the NIST PQC Forum over the prior years, I can easily imagine the rough context of any such situation. (Who really wants to have a bitter fight via email messages on an Internet forum?) I am aware there was a recent "mandatory call" for pure-mlkem that recently failed. It might surprise those who know me to hear that I agree with that mandatory call failing. I do not think it's the proper time for pure-mlkem to be mandatory. Nonetheless, there is a distinct difference between a mandatory requirement for ML-KEM and simply an official option for ML-KEM-only. Currently, I represent a major vendor in the space of secure communications. For our primary communications platform, we intend to offer ML-KEM-only as the straightforward implementation of TLS for our systems, at $100B+ scale. (I note a prior response in this thread indicates that gmail is doing the same.) That is not to say that we don't intend to have hybrid systems. In particular, for many of our systems, we are actively exploring systems that hybridize in an amortized way between ECC (e.g. X25519) and lattice-based cryptography (ML-KEM-1024). That is, sometimes the significantly smaller bandwidth of Curve25519 based ciphertexts is inherently necessary for current systems. So, this gets to my *main first objection* to the current state of discussion (as held at the 125 meeting): As a vendor, I believe both in the (current) security of X25519 and the (long-term) security of ML-KEM, while being cognizant of the quantum threat and HNDL. However, the efficiency profiles differ dramatically, and different systems have different needs. In contexts of challenging communication environments, we require the low bandwidth of X25519 in order to have reliable communications. Yet on the other hand, when considering a basic TLS-based system -- e.g. a webserver connected to high-speed fiber with convenient access to a reliable PKI, we believe that hybridizing between ECC+ML-KEM is the *worst of both worlds.* In particular, consider the performance profiles of these two schemes: X25519 is noticeably slower to compute in parallel, while smaller in bandwidth; ML-KEM is noticeably faster to compute in parallel, while higher in bandwidth. *In the most common/applicable use-case of TLS 1.3* -- i.e. high-bandwidth traffic with millions of billions of connections, over reliable infrastructure -- bandwidth is significantly less of a problem, and computation constraints are the major concern. Simply put, for TLS 1.3, pure-mlkem is the obviously correct solution if you want high-performance solutions -- modulo security considerations (let's turn to that now.) My *second objection* to the state of the discussion regards the call for CFRG/IRTF to render a fresh opinion on the cryptography of ML-KEM to the TLS WG: There has been a full decade of entirely open, international analysis and debate over the security of quantum-resistant cryptography through the NIST PQC process. ML-KEM was fully vetted through this process (despite various detractors that may feel otherwise). Yet, the discussion in the TLS WG is not cryptographically detailed in the nature. *No new cryptanalyses have been offered.* Just some grumbling. Do we expect that a call to the CFRG will report something significantly different in terms of number theory and computational analyses that NIST's decade-long, international, open, and highly visible process did not? I think that seems wildly unlikely. My *third objection* to the discussion regards the talk of "Hard No"s to prior WGLC's for pure-mlkem: Certainly, there can be many "absolutely not!"s in the discussion of whether to adopt this particular draft. However, that seems to run counter to my understanding of RFC 7282 in terms of the chairs' opinion on whether rough consensus has been achieved. Again, I am not calling for a mandatory use of ML-KEM-only; and indeed, I plan to use ECC in various systems (with different performance constraints attached to them than the typical TLS use-cases). However, to /deny/ the option for ML-KEM-only to be used in TLS 1.3 would seem to be a shocking repudiation of the decade-long, international effort to that led to that cryptographic standard. Is it really an acceptable outcome that a more visible, international process led to the standardization /of the primitive,/ and yet -- in the most obvious use-case in protocols (TLS 1.3 -- which has been the motivating protocol in every lecture I've given in university grad courses for years now) -- it should be fundamentally /disallowed/? My *fourth objection*, following up: At the 125 meeting, someone commented that "well, hey -- IETF standardized the codepoints for ML-KEM. Isn't that enough?" No! Many vendors will only support ML-KEM-only TLS if there is, specifically, an RFC from IETF specifying such. A very common goal in industry these days is to ensure "*no vendor-lock-in*" for various products. However, if this WG decides to disallow an RFC on ML-KEM-only TLS, then many vendors will not produce products conforming to the natural outcome of the NIST PQC process. This would induce a punishing market effect on the broader vendor ecosystem from a relatively obscure conversation in this WG's mailing list. So, my general call is for the following: 1) Adopt hybrid-ECC-MLKEM for TLS 1.3 2) Adopt ML-KEM-only for TLS 1.3 2b) I strongly encourage neutral language in the RFC. 2c) "Proponents of hybrid" is not quite accurate, as there are not "opponents of hybrid," but there *is* a significant vendor-community that is *also* a proponent of ML-KEM-only, for specific systems. Finally, I've had advice from a wise man who's active in this WG and many others: "Don't come, fly over, and drop bombs, then never continue the conversation again." Understood! I'm happy to be here until the cows come home. I also intend to share the (alarming) status of the current discussion with others in the vendor community that want /an option/ for ML-KEM-only in TLS 1.3. This is *not* an effort to "ballot-stuff," but a genuine attempt to make others aware that the conversation has gone so far here, without sufficient representative input, that a standards/RFC outcome is near that is entirely unexpected by many vendors. Kind regards, --Daniel Apon On Mon, Mar 23, 2026 at 11:52 AM Joseph Salowey <[email protected]> wrote: > > > On Sun, Mar 22, 2026 at 11:04 AM Stephen Farrell < > [email protected]> wrote: > >> >> Hi Joe, >> >> On 22/03/2026 17:49, Joseph Salowey wrote: >> > ML-KEM WGLC Update >> > >> > We are working through issues brought up during the working group last >> > call. We believe addressing these issues is necessary to determine if we >> > have rough consensus to move forward. We expect the author to address >> the >> > following points: >> > >> > * Key Reuse >> > * Text for preferring Hybrids >> > * Whether to include motivations (see Liaison Statement) >> > >> > We expect resolving these issues will take a few weeks after which we >> will >> > run a targeted consensus call to see if text changes are acceptable to >> the >> > working group. >> >> The above seems to me unclear and hard to understand. >> >> Are you saying that the 2nd WGLC failed due to a lack of rough >> consensus? (Or not?) >> >> > [Joe] The chairs have determined that there is no rough consensus, but > people have requested changes. The chairs have asked the author to see if > changes to the draft make a difference. > > >> Either way, I don't know what you mean by a "targeted consensus >> call" - if the 2nd WGLC failed, then surely another WGLC will be >> needed or the draft is just stalled. If the 2nd WGLC succeeded, >> then (that'd be a surprise and) I don't get why some other consensus >> call would be needed, nor for what. >> >> > [Joe] The intent here is to run a specific consensus call on the changed > text. If you suggested changes in the draft in the previous WGLCs then we > ask you to review and state whether the changes have helped (or not). If > you did not recommend changes, then your position will remain the same, > unless you state that you are reconsidering. > > >> So I'm confused, sorry. >> >> I do get that sometimes the result of a WGLC is "go ahead after >> fixing these nits" but I don't see how that applies in a situation >> with the fairly fundamental controversies we've seen related to >> this draft. >> >> Cheers, >> S. >> >> >> >> > Thanks, >> > >> > Sean and Joe >> > >> > >> > _______________________________________________ >> > 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] On Mon, Mar 23, 2026 at 11:52 AM Joseph Salowey <[email protected]> wrote: > > > On Sun, Mar 22, 2026 at 11:04 AM Stephen Farrell < > [email protected]> wrote: > >> >> Hi Joe, >> >> On 22/03/2026 17:49, Joseph Salowey wrote: >> > ML-KEM WGLC Update >> > >> > We are working through issues brought up during the working group last >> > call. We believe addressing these issues is necessary to determine if we >> > have rough consensus to move forward. We expect the author to address >> the >> > following points: >> > >> > * Key Reuse >> > * Text for preferring Hybrids >> > * Whether to include motivations (see Liaison Statement) >> > >> > We expect resolving these issues will take a few weeks after which we >> will >> > run a targeted consensus call to see if text changes are acceptable to >> the >> > working group. >> >> The above seems to me unclear and hard to understand. >> >> Are you saying that the 2nd WGLC failed due to a lack of rough >> consensus? (Or not?) >> >> > [Joe] The chairs have determined that there is no rough consensus, but > people have requested changes. The chairs have asked the author to see if > changes to the draft make a difference. > > >> Either way, I don't know what you mean by a "targeted consensus >> call" - if the 2nd WGLC failed, then surely another WGLC will be >> needed or the draft is just stalled. If the 2nd WGLC succeeded, >> then (that'd be a surprise and) I don't get why some other consensus >> call would be needed, nor for what. >> >> > [Joe] The intent here is to run a specific consensus call on the changed > text. If you suggested changes in the draft in the previous WGLCs then we > ask you to review and state whether the changes have helped (or not). If > you did not recommend changes, then your position will remain the same, > unless you state that you are reconsidering. > > >> So I'm confused, sorry. >> >> I do get that sometimes the result of a WGLC is "go ahead after >> fixing these nits" but I don't see how that applies in a situation >> with the fairly fundamental controversies we've seen related to >> this draft. >> >> Cheers, >> S. >> >> >> >> > Thanks, >> > >> > Sean and Joe >> > >> > >> > _______________________________________________ >> > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
