Hello everyone, Apologies for any mistakes with utilizing the email list or bad headers; I am getting familiar with the WG. As it may be relevant for my following expressions, I have been a software developer/engineer for several years and am a cybersecurity student.
I reiterate that I do not support the publication of this document. Just because some people want to make it easier for others to use a less powerful security mechanism doesn't mean that the IETF needs to assist them. Anyone who really wants to use ML-KEM solo can do so. Thank you to everyone for the excellent concerns raised to protect users. To those who are asking that we hurry to publish, I would ask for patience. This document could affect millions of people for decades to come - it is not something to be pushed out casually. The IETF uses (rough) consensus so that all concerns may be heard and considered. I appreciated the table-like ISO document someone linked that had a list of issues raised, the category the issue was placed into, and a documented response, so that it was clear that all grievances had been addressed. Adopting such a process here might be useful in the future. Sincerely, Sam Leavin On Tue, Jul 7, 2026 at 7:47 PM <[email protected]> wrote: > Send TLS mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TLS digest..." > > Today's Topics: > > 1. Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) > (Jacob Appelbaum) > 2. Re: Algorithm agility (Re: Re: WG Last Call: draft-ietf-tls-mlkem-08 > (Ends 2026-07-08)) > (Nico Williams) > 3. Re: New Version Notification for > draft-sullivan-tls-xof-ciphers-00.txt > (Nick Sullivan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 7 Jul 2026 22:54:50 +0000 > From: Jacob Appelbaum <[email protected]> > Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends > 2026-07-08) > To: Joseph Salowey <[email protected]>, [email protected], > [email protected], [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Greetings tls-chairs and hello to other TLS-related folks, > > On 6/24/26 17:00, Joseph Salowey via Datatracker wrote: > > This message initiates a new Working Group Last Call for draft-ietf- > > tls-mlkem[1], which defines standalone ML-KEM key establishment for > > TLS 1.3. The main question before the working group is: "Should the > > working group publish a document specifying stand alone ML-KEM?". > > I do not support the publication of this document. > > > If > > there is rough consensus then we will push to refine and publish the > > document; otherwise, we will stop discussing the draft and not > > progress it. Please respond to this call indicating whether you > > support publishing a document specifying a stand alone ML-KEM. > > Please refrain from further discussion on this topic as most > > arguments have been discussed multiple times. > > > > Why are we holding this consensus call now? > > > > Significant developments have occurred both within this document and > > in the broader TLS ecosystem to address the concerns raised in the > > last WGLC. Therefore, the third consensus call is warranted. We ask > > the working group to consider document publication in light of these > > recent changes: > > > > Unfortunately, the reasons listed do not address several of my concerns. > > One of my primary concerns is the intentional removal by NIST of the > hash call over the `m` value in FIPS 203 for ML-KEM before it is used > internally by ML-KEM.Encaps(). Please consult Appendix C and > specifically the third bullet point of C.1 on page 47 of FIPS 203 [0] > for NIST's disclosure about this matter. The developments listed by Joe > and Sean below do not mitigate the risk introduced by this change to > Kyber as part of standardizing ML-KEM. > > To Nadim and Usama's credit: I found their formal modeling to be useful. > When I last looked at the (symbolic) models, I understood that they did > not model the RNG covert channel leakage concerns. This makes sense as > it is internal to one part of ML-KEM, and the carrier of the covert > channel is not directly visible on the wire as the covert channel itself > is encrypted (e.g., the ciphertext is visible on the wire, but the > covert channel encoded through `m` is not directly modeled as such). > This is an unfortunate gap with symbolic models generally where > cryptographic primitives are considered perfect as it makes some > internal issues invisible. It is not a problem with their work; it is a > problem with the primitive itself and the abstraction of symbolic models. > > Additionally the security considerations of the draft document in question: > > - do not mention outstanding technical concerns in the NIST process > - do not link to the official comments in the NIST process > - do not mention outstanding technical concerns in IETF discussions > - do not give sufficient warning to those who are not cryptographers > - do not give sufficient warning to cryptographic protocol engineers > - do not mention the FIPS 203 requirement for NIST-approved randomness > generation > > The last item is especially relevant - do endorsers of this non-hybrid > ML-KEM draft all use ML-KEM only with NIST-approved randomness > generation sources? Do they realize that this requirement is part of the > security analysis? Again, hashing of `m` was removed intentionally and > it is explained as part of the third bullet point of Appendix C in C.1 > on page 47 of FIPS 203 [0] for NIST's disclosure: "As this standard > requires the use of NIST-approved randomness generation, this step is > unnecessary and is not performed in ML-KEM." The security considerations > of this document most certainly do not state that a NIST-approved > randomness source is _required_. Nor do they explain that the removal of > the hashing is considered secure only if that _required_ NIST-approved > randomness source is used. The draft does not raise this clear and > serious warning. > > The introduction by NIST of a covert channel in the design of Kyber as > part of standardizing ML-KEM may lead to serious problems with TLS 1.3. > No draft should promote ML-KEM without closing this covert channel. > Instead, this draft implicitly relies on a NIST-approved randomness > source as the mitigation for that covert channel. This is uncomfortably > similar to how Dual_EC_DRBG, once NIST-approved, ended up being used in > the real world despite being suitable for such covert channels. > > Ideally, I suggest closing the covert channel in the draft because doing > so is trivial. This is separate from hedging with a hybrid construction. > Relatedly, TLS 1.3 should also not reveal system randomness directly to > the wire as several TLS implementations do today. > > Taken together, an adversary with a carefully placed kleptographic RNG > backdoor will not even need an Extended Random draft this time around. > > I note that NIST did not engage with many of the official 2023 comments > [1]. That limited engagement is concerning in light of NIST’s later > disclosures about Dual_EC_DRBG, including its own email disclosure [2] > between Don Johnson and John Kelsey. Dual_EC_DRBG also remains present > in at least one widely deployed cryptographic library. > > For example, Bouncy Castle still contains a DualECSP800DRBG > implementation [3][4] whose default P-256 Q point matches the > (backdoored) value listed in the now-withdrawn NIST SP 800-90A Appendix > A.1.1 [5, page 77]. > > As the IETF takes no stance on the validity of patent claims, I propose > a simple compromise to move the document along: in the next iteration of > the draft, I would like to see the IETF require any ML-KEM > implementation to hash `m` as Kyber did, and to state explicitly that > relying on a NIST-approved randomness source is not an adequate > mitigation for this concern. If reliance on NIST-approved randomness > generation is retained, it should at least be explicitly required rather > than implicitly endorsed by being buried deep within a comment in an > appendix to FIPS 203. Such changes are interoperable even if other > ML-KEM implementations do not make them. Hashing destroys the structure > needed to exploit Dual_EC_DRBG and other similar kleptographic > constructions. > > The draft could also encourage a similar strategy for all random bytes > fields in TLS 1.3 that currently come directly from the system but that > change is a better fit for a different draft. I would want to see > changes made to ML-KEM and TLS 1.3 before I would feel confident that > TLS 1.3 with ML-KEM was providing protection against serious large-scale > adversaries. > > I have additional technical concerns as well as some additional > technical mitigations. I am happy to share draft analysis and code with > interested participants. > > Kind regards, > Jacob Appelbaum > > [0] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf > [1] > > https://csrc.nist.gov/files/pubs/fips/203/ipd/docs/fips-203-initial-public-comments-2023.pdf > [2] > > https://csrc.nist.gov/CSRC/media/Projects/Crypto-Standards-Development-Process/documents/Email_Oct%2027%202004%20Don%20Johnson%20to%20John%20Kelsey.pdf > [3] > > https://downloads.bouncycastle.org/java/docs/bcprov-jdk14-javadoc/org/bouncycastle/crypto/prng/drbg/SP80090DRBG.html > [4] > > https://raw.githubusercontent.com/bcgit/bc-java/main/core/src/main/java/org/bouncycastle/crypto/prng/drbg/DualECSP800DRBG.java > [5] > > https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-90a.pdf > > > > - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a > > separate consensus call, the WG agreed to promote the X25519MLKEM768 > > hybrid group to Recommended: Y in the IANA registry. Consequently, > > the IANA registry will reflect a clear community preference for a > > hybrid because Recommended: Y clearly indicates this while the > > standalone ML-KEM groups defined in this draft remain Recommended: > > N. The updated security considerations in [1] reference the IANA > > registry to emphasize this preference. > > > > - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG > > recently reached consensus to explicitly prohibit key share reuse > > across connections in TLS 1.3. The new text changes the guidance > > from SHOULD NOT to a strict MUST NOT. This resolves the concerns > > regarding static key reuse and its associated privacy and forward- > > secrecy risks for ML-KEM. > > > > - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and > > hybrid KEM groups in TLS 1.3. This supports other results which show > > that KEMs are secure when used in TLS 1.3 and that hybrid groups are > > secure even if one of the components is compromised. > > > > - Liaisons: We received liaison statements from multiple SDOs > > including O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing > > support for the publication of draft-ietf-tls-mlkem as an RFC as > > they rely on the IETF to provide a stable normative reference. > > > > Please note that a third-party IPR disclosure exists [5] against > > this document regarding patents related to the underlying ML-KEM > > algorithm. This IPR declaration has not changed since the last WGLC. > > As a reminder, per BCP 79, the IETF takes no stance on the validity > > of patent claims, and the working group may decide to proceed with a > > technology despite IPR disclosures if it decides that such use is > > warranted. > > > > Conduct Reminder: Given the heated nature of previous discussions on > > this topic, participants are strongly reminded to adhere to the IETF > > Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep > > feedback professional, technical, and focused on the document's > > text. > > > > This working group last call will end on 2026-07-08. > > > > Joe and Sean > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ [2] > > https://datatracker.ietf.org/liaison/2198/ [3] https:// > > datatracker.ietf.org/liaison/2151/ [4] https://datatracker.ietf.org/ > > liaison/2148/ [5] https://datatracker.ietf.org/ipr/search/? > > submit=draft&id=draft-ietf-tls-mlkem > > > > _______________________________________________ TLS mailing list -- > > [email protected] To unsubscribe send an email to [email protected] > > > ------------------------------ > > Message: 2 > Date: Tue, 7 Jul 2026 18:12:32 -0500 > From: Nico Williams <[email protected]> > Subject: [TLS] Re: Algorithm agility (Re: Re: WG Last Call: > draft-ietf-tls-mlkem-08 (Ends 2026-07-08)) > To: Soatok Dreamseeker <[email protected]> > Cc: Jan Zerebecki <[email protected]>, [email protected] > Message-ID: <ak2H4BW7BTuTgKg7@ubby> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jul 07, 2026 at 06:48:59PM -0400, Soatok Dreamseeker wrote: > > > I don't know what you're arguing. If your argument is "don't get this > > > wrong", then I agree 100%. If your argument harkens back to what I was > > > originally responding to, namely that algorithm agility is bad, then I > > > disagree 100%. > > > > If you wonder aloud why people are against algorithm agility and then are > > astonished when someone explains how poorly thought-out algorithm agility > > can introduce security footguns, I don't know what you expected. The > > concept of algorithm agility is very broad. > > That's not really an answer to my question is it. It comes off as a bit > of an attempt at a personal gotcha. > > Past failures to get algorithm agility right do not and cannot mean that > we must not do algorithm agility because it is unavoidable due to > cryptographic algorithms aging out. There is irreducible complexity > involved. > > The debatable points are about how to do it, not whether to have it. To > that point I expressed a clear preference for doing it in-band, _inside > TLS_ or whatever the protocol is rather than have to design new > protocols with negotiation _somewhere_ and downgrade resistance. If > you're arguing for algorithm agility not-that-way, then say that. > > Nico > -- > > > ------------------------------ > > Message: 3 > Date: Tue, 7 Jul 2026 19:45:37 -0400 > From: Nick Sullivan <[email protected]> > Subject: [TLS] Re: New Version Notification for > draft-sullivan-tls-xof-ciphers-00.txt > To: [email protected] > Message-ID: > <CAOjisRyPxrdm6=Dyo+7kUscZCM2mjZCkSx7-rqtT7f= > [email protected]> > Content-Type: multipart/alternative; > boundary="0000000000008fd5bc06560dfd63" > > Thanks, everyone. Let me take this person by person: restate each point so > we're on the same page, then say where I land. (forgive the formatting, > monospace was needed) > > *John Mattsson* > > You're suggesting the deck should do much more: fine-grained services from > one deck function instead of assembling a protocol out of separate > symmetric primitives, a lightweight roll for cheap per-message ratcheting, > and the key schedule and record encryption folded into one running duplex > rather than handed to a separate AEAD. > > We agree on the starting point: HMAC and HKDF are a poor base, and > replacing them is the whole point of the draft. Where I stop short of you > is going all the way to a duplex that does everything. It's an elegant end > state, but not this draft: I want the new surface small enough to analyze, > and record protection is throughput-bound, where a separate AEAD is the > right tool for now. Ilari pushed back on the roll and the duplex directly, > so I'll pick those up under him. > > *Markku Saarinen* > > You're pointing at the hardware chicken-and-egg: Keccak is fast in silicon > but gets little of it, because software keeps reaching for AES and GCM, and > you expect ML-KEM, ML-DSA, and full-round Keccak instructions to finally > break the cycle, so we should build for where the hardware is heading. > > That's the premise the draft runs on: once Keccak is already in the stack > for SHA-3, ML-KEM, or ML-DSA, the schedule reuses it for free. And when the > full-round hardware you describe arrives, a duplex record layer, the kind > of thing your BLINKER prototyped, is the natural next profile, which is > exactly the endpoint John is after. > > *Ilari, on record protection* > > You already made the case against John's two record-layer ideas: a > per-message roll runs into DTLS reordering and loss, and your own Keccak > duplex record experiment wasn't fast enough to replace the AEAD. > > I agree, and that's why -00 leaves record protection to the AEAD and keeps > KeyUpdate a full ratchet rather than a roll. > > *Martin Thomson* > > You'd keep the KDF choice off the cipher suite and negotiate it on its own, > with 0 reserved for HKDF, and you flagged the cost: until the server > selects, a client can be carrying several schedules at once, so keep the > set small. > > Fair, and I'll take it. -00 bundles them today: > > -00: cipher suite = (AEAD, schedule) one code point, bundled > -01: cipher suite = AEAD > KDF extension = { 0 = HKDF, deck, ... } negotiated separately > > That's a real change to how the draft frames itself, not a small edit, but > I'd rather make it than defend the coupling. On the parallel cost, the case > that bites is offering HKDF next to the deck, since that's SHA-2 against > Keccak, two different hashes to carry until the server picks, the same cost > TLS already pays for hash-agile suites. The two deck profiles aren't a > second axis: they're one design at 12 and 24 rounds, SHAKE256 being the > full-round one for FIPS conformance, so offering both is one codebase at > two round counts. Keep the offered set small and that's the whole of it. > I’d prefer TurboSHAKE if we’re selecting only one, but if FIPS is a target, > people may prefer the “too much crypto” version for compliance reasons. > > *Ilari, on the schedule* > > You think -00 looks complicated, and you sketched a leaner one: a two-part > [Left | Right] state, a Rachet that carries the Left half forward as the > chain, and an Output off the Right half for every derived value. Here are > the two side by side, aligned at the stage secrets the way the appendix > aligns 8446 (no PSK, matching the count below): > > deck (-00) Ilari > > PSK PSK > | absorb; Ratchet | Rachet > v v > early_secret early_secret [L|R] > | | > | absorb DHE, TH_SH | Rachet(Left, DHE) > v v > H trunk (handshake) handshake_secret [L|R] > | Fork: hs traffic | Output(R): hs traffic > | | > | Ratchet | Rachet(Left) > v v > main_secret master_secret [L|R] > | absorb TH_SF | > v | > T trunk (application) | Output(R): app traffic, > | Fork: app traffic, | exporter, > | exporter, resumption | resumption > > It's essentially the same tree. The one structural difference: you keep an > explicit handshake_secret, where the deck absorbs the key-exchange secret > into a running trunk and forks from it, so the deck has two stage ratchets > where you have three. > > On cost, counted on your scenario (no PSK, transcript set aside, since > that's what your 15 covers): > > deck Ilari > stage transitions 2 3 > traffic secrets 4 4 > record keys 4 4 > Finished (client+server) 4 2 > exporter 1 1 > resumption 1 1 > total 16 15 > > So 16 to your 15. The single extra call is the separate MAC key: the deck > spends two per Finished, expand finished_key then MAC, where you spend one > Output, so plus two across the two Finisheds, minus one because the deck > folds the handshake extract into an absorb instead of a third ratchet. One > call apart, and that call is the tradeoff. Your Finished keys off > Right(BaseKey), the traffic secret you also expand into its record keys, so > a proof has to argue that one key is safe for both; the deck derives a > separate finished_key, used for that MAC and nothing else (on SHAKE256, > exactly KMAC256). One is a call cheaper, the other easier to reason about. > Both are one XOF per derived value, which is where the saving over an HKDF > schedule comes from, for both. > > On the proof, you're right that it needs one, and -00 is no different. A > running trunk isn't the discrete extract-then-expand shape the existing TLS > 1.3 results assume, so the chaining needs fresh analysis either way. The > leaves are where the two diverge. The draft's leaves are built on analyzed > constructions: the derivation is a keyed sponge with concrete keyed-duplex > bounds, and the MAC is KMAC, whose framing gives the keyed separation and > keeps a MAC from colliding with a derivation. Rachet and Output are one > bare XOF at one domain, keyed by a prefix, so the keyed-PRF step and the > MAC-versus-derivation separation are still open. The output carries > HKDF-Expand-Label's labels. Rachet has none and leans on the chained state > to keep the stages apart. Nothing there looks unsound, just less of it > already written down and analyzed. > > *-01 action items* > > Pull the KDF into its own extension, 0 = HKDF; keep the separate-key MAC; > leave record protection to a later profile; and take the running-state > schedule to a real proof. > > Thanks, all! This is the read I was hoping for. Keep it coming. > > Nick > > On Tue, Jul 07, 2026 01:49 PM, "Markku-Juhani O. Saarinen" < > [email protected]> wrote: > > > Yep, > > > > > > For many years Keccak/SHA3 has had this chicken-and-egg problem wrt AES & > > GCM, and SHA-2 too. While Keccak is faster in actual hardware, current > > processors allocate a lot of real estate to the AES S-Boxes and carryless > > multipliers, and hardly anything to Keccak. As a result, software > engineers > > keep using AES & GCM even more, not SHA3 at all -> processor makers > invest > > even more gates on AES & GCM and still hardly anything in SHA3. > > > > > > With ML-KEM and ML-DSA making heavy use of Keccak, we may finally break > > this cycle of doing 90s crypto forever -- and finally get full-round > Keccak > > vector instructions (that compute the entire f1600 in a few dozen cycles) > > on more processors. This is "full keccak" approach substantially faster > > than the partial SHA3 instructions available in, say, ARMv9. Such a > Keccak > > engine would, of course, make Duplex AEADs competitive or faster than > AES & > > GCM. > > > > > > At the RISC-V PQC TG, the official full Keccak instruction has a > > ratification plan targeting early next year. So, at present it is > > restricted to experimental CPUs like the KaruCore processor we use as an > HW > > PoC (but it boots Linux and runs stock OpenSSL benchmarks!) Here's a > > silly blog I wrote about running PQC benchmarks on it: > > https://karucore.com/posts/pqc-and-keccak-on-karu/ > > > > > > *"TL;DR: The Keccak instruction vkeccak.vi <http://vkeccak.vi> proposed > in > > the PQC TG of RISC-V International is implemented in our karu64 core and > > makes standard lattice-based PQC algorithms go 50% faster. The more you > > optimize the rest, the bigger the Keccak share becomes and the greater > the > > relative benefit of having Keccak."* > > > > > > I want "nice things" ! When building clean-slate things (brand-new CPUs > > and brand-new TLS handshakes), we don't always have to consider the > > limitations of technologies that we fully expect to go away anyway. And > in > > the meanwhile the older systems can happily coexist with the new. > > > > > > Cheers, > > -markku > > > > On Tue, Jul 7, 2026 at 7:54 PM Ilari Liusvaara <[email protected] > > > > wrote: > > > >> On Tue, Jul 07, 2026 at 06:08:10AM +0000, John Mattsson wrote: > >> > > >> > This seems like a great start! > >> > > >> > Instead of performing a full permutation for the relatively infrequent > >> > key updates, it may be preferable to also use a lightweight "roll" > >> > function to support inexpensive per-message ratcheting, similar to the > >> > approach used by the Signal protocol. > >> > >> This seems to run into problems with reodering/loss in DTLS and AES > being > >> slow to rekey (Chacha is much faster here). > >> > >> > >> > The current draft still hands off record protection to a separate > AEAD, > >> > with the deck function merely deriving the traffic keys. In my view, > >> > this leaves one of the most compelling opportunities unexplored. The > >> > key schedule and record encryption could be integrated into a single > >> > running duplex object. > >> > >> Unfortunately, Keccak does not seem to be very good for this. > >> > >> I recently experimented with using Keccak for record protection. Testing > >> core loop (the dominant cost for long messages) of an impractical AEAD > >> (8-way interleaved TurboKeccak in duplex mode) gave ~6GBps on > >> AMD 7900X(@65W). > > > > > >> > >> -Ilari > >> > >> _______________________________________________ > >> 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] > > > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 16196 bytes > Desc: not available > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > ------------------------------ > > End of TLS Digest, Vol 264, Issue 123 > ************************************* >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
