[TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3

[Jacob Appelbaum <[e-mail]>]

Hello Bas,

Thanks for taking the time to reply and to engage, I appreciate it. My 
comments below are intended in a constructive manner.

On 4/23/26 14:12, Bas Westerbaan wrote:
> Hi Jacob,
> 
> The question becomes: which hybrid?

This draft offers none currently, so I suppose none is the only option 
under discussion. That is the cause of much consternation, I might add.

If as an author you think that it should, I would suggest as many of 
them as possible, ideally all of them. Standardize the Cartesian Product 
and sort them into buckets based on various properties. Only Recommend=y 
for hybrid constructions that meet certain properties. I still wouldn't 
want to have a PQC only option, frankly.

> There is no value in deploying
> PQ if both ends don't support the same thing, and installing 20
> certificates is not practical.

Practicality seems rather subjective or at least highly contextual. Most 
of the HTTPS infrastructure would be impractical without the automation 
that is already in place. It is natural to extend that automation to 
cover this kind of problem as well, isn't it? If browser vendors want to 
work everywhere, they'll likely need to support a set of cryptography 
that is global. If server vendors want to work with all clients, the 
same is true. If a site has a target audience with a preference, I 
suspect they'll need to tune their configs accordingly.

We certainly agree that there must be an overlap of supported options 
between clients and servers. With automatic certificate issuing at no 
cost to users, I wonder if we might simply automate a lot of this away.

For the open web, we will probably see configuration profiles that are 
very different from other more specialized TLS deployments. A few 
powerful vendors unfortunately control a lot of the discussion. It is 
both sad and slightly amusing to see developers of multi-billion dollar 
companies hem and haw about not planning on supporting composite 
signatures. Compared to the engineering effort of writing a web browser 
where much of the security boils down to ensuring that there aren't 
forged signatures accepted by the browser, I observe that it is 
worthwhile to develop, and to support composite signatures. Some of 
those companies are subject to regulation and for better or worse, they 
will probably be brought to heel. I trust Europe's regulators will 
attempt to do what the Free Market hasn't done so far...

> I've tried for years to whittle down
> the number of variants for years. While everyone agrees there are
> too many variants, no one agrees on which one to keep. (I'd opt for
> MLDSA44P256.)
My position is different. I do not mind a large number of variants, I 
care about the diversity of the variants, and other design factors. The 
primary and most important goal is to actually achieve security. If we 
aren't doing that, efficiency and other kinds of yak shaving is utterly 
irrelevant. Two variants that have the same hardness assumption and that 
are both the result of a NIST process might as well be a single bad 
option in my book.

> While I prefer hybrids over pure, I also prefer PQ
> over not having PQ, so pure signatures seem to be the most
> compatible and thus secure choice.
> 

It is almost a triviality but as a matter of terminology, I don't really 
like the term pure. It implies the other option is impure or somehow 
that there is something wrong with it. Maybe someday when quantum 
computers humble us all.

Preferably the terminology from draft-ietf-lamps-pq-composite-sigs 
appears a little better even though they also use "pure" a few times. I 
hope they'll drop the use of "pure" in the next draft. This is such a 
minor nit to pick that it may not be worth the text editing time but I 
would be more supportive of their draft if they did make that edit.

In draft-ietf-lamps-pq-composite-sigs the authors use the term Trad for 
Traditional which is amusing and it fits. It seems that it would be nice 
if they also used the term Rad for the new, hopefully post-quantum, 
cryptographic primitives. The term Rad vis-a-vis Trad more correctly 
reflects the magnitude of the change: it is a radical departure from the 
Traditional cryptography we've been using for most of our lives. They 
also use the term "Post-Quantum/Traditional (PQ/T) Hybrids" and cite 
RFC9794.

So in the spirit of that draft, I would say that I consider PQ/T Hybrids 
as the baseline. Neither Trad or rad cryptography alone is secure in the 
context of the (two) meaningful definitions of security.

Adding to the notion of PQ/T Hybrids, I want those hybrid constructions 
to have some additional considerations. These considerations aren't 
normally discussed by computer scientists or mathematicians unless they 
minored in political science or at least have some sense of the reality 
of how the sausage is made.

One of the considerations is related to raw RNG outputs as I mentioned 
in my NIST comments that I cited in my previous email. I trust that 
you've read my comment to NIST[0] but if not, please consider doing so. 
In short, I don't want raw RNG outputs from the system to the wire at 
all and certainly not to "save" a single hash function call.

Unfortunately for some of the newly standardized PQC, that matter is 
settled and deviation is subject to patent controls. What a coincidence! 
Regardless, I certainly do not want that property in both choices at the 
same time. We certainly do not want or need another 
Dual_EC_DRBG/Extended Random situation.

Another perhaps more interesting consideration is to have geopolitical 
diversity.

It would be good to see a competition run that is similar to the PHC, 
CAESAR, and/or eSTREAM with the results as one part of any PQ/T Hybrid 
composition. This will take a while, so lets start by using what we're 
already using, add PQC and use a secure combiner as the baseline.

This should be a PQ/T Hybrid that is comprised of at least two systems 
that are taking different approaches, ideally designed by different 
parties or at least strongly promoted by different organizations, and 
with different considerations that have comparable security levels.

To be completely blunt: I do not mean a system that is designed by 
academics in Europe and elsewhere, tweaked by NIST/NSA and then stamped 
with NIST approval in America as controlled by their patent licensing. 
That result, while important is what the American government has decided 
that they will tolerate because it benefits them. That looks diverse but 
it does not meet my diversity criteria when composed with another NIST 
choice where they have or have had a controlling interest.

Consider that the US government and/or US government contractors that 
are required to use NIST cryptography usually do not need to keep their 
own communications secret from NSA as a security goal. NSA in many cases 
has the job of watching those very agencies for (legitimate or 
otherwise) reasons. Their use of, and approval of, a system does not 
mean there is a lack of (NOBUS style or otherwise) cryptographic 
sabotage. Certainly it is also obviously part of NSA's job to break that 
cryptography in practice when it is any other government using NIST's 
cryptography. Suite B was aptly named wasn't it? It was literally the B 
team all along.

Attempts at humor aside and as a practical matter, I want to see 
compositions that do not rest on NIST processes alone. For example, if 
ML-DSA is in use, I'd also like to see it paired with Ed25519 or even 
Ed448. In that case, we'd have NIST approving of all three choices but 
they had no hand in creating the latter two as far as I understand the 
history. Similarly, I would like to see FrodoKEM composed with the NIST 
curves and so on. I don't particularly want to use a GOST hash function 
but if I must, I'd like to pair it with hash function that doesn't have 
the same weird structure and it certainly shouldn't be paired with 
something else made by the same organizations. I suppose I prefer my 
PQ/T Hybrid algorithms to be designed by opposing Adversaries and then 
analyzed by people with interests aligned to mine.

> Also note that the threat is quite different. While attacking the
> KEM allows for completely silent Enigma style attacks, an attack on
> the authentication leaves more direct evidence.

It is worth writing out every threat systematically. I have not seen 
that done on the list yet but I may have missed it.

When we speak about targeted and mass surveillance for the purposes of 
bulk decryption, a common refrain is that a careful Adversary wouldn't 
want to use any decryption information that would tip their hand. Yet we 
know that PROJECT BULLRUN style decryption of (tens of) thousands of 
IPsec sessions is possible without almost anyone noticing except by 
reading leaked internal NSA documents. That's ten year old news and the 
stated plan of the NSA ten years ago was to scale to a more serious 
collection volume. That data was certainly used including in political 
espionage, and even drone assassinations. Heavy stuff!

The Enigma style attack considerations are a valid model but I don't 
think they are the only correct model and I trust my examples above have 
perhaps moved you a little. Getting caught isn't so simple, and even if 
one is certain that they've caught something, attribution remains hard, 
and a follow up course of action may be unclear.

To your point, some targeted attacks may leave evidence, and then we 
have a problem of finding, analyzing, and then taking action based on 
that evidence. In the case of a successful MITM attack or in the case of 
a forgery to be checked many years from now (e.g. time stamping with 
TLS, verifying DKIM signatures for leaked email authenticity, etc), I am 
not sure sure that an Adversary really has much of a problem. Even if a 
forgery were detected, if it was long after the fact many people would 
probably conclude that a keypair had been stolen before they'd assume 
the cryptography was broken. There are useful bits of infrastructure 
here and there such as CT logs... but is it always possible to take 
evidence and turn it into action? What would that even look like for 
KEMs or DSAs in practice? As a pointed example - what did Microsoft do 
in response to NSA/GCHQ and their other spooky friends exploiting 
MD5[1][2] for use in their FLAME malware, again? Almost certainly 
nothing that mattered to the people already compromised by FLAME.

Kind regards,
Jacob Appelbaum

[0] 
https://csrc.nist.gov/files/pubs/fips/203/ipd/docs/fips-203-initial-public-comments-2023.pdf
[1] 
https://cseweb.ucsd.edu/classes/wi21/cse127-a/slides/18-advancedthreats.pdf
[2] 
https://s3.amazonaws.com/s3.documentcloud.org/documents/1150433/lobban-nsa-visit-precis.pdf

> 
> On Thu, Apr 23, 2026 at 12:53 AM Jacob Appelbaum
> <[e-mail]> wrote:
> 
>> Hello,
>> 
>> On 4/9/26 21:30, Sean Turner wrote:
>>> This is the working group last call for Use of ML-DSA in TLS
>>> 1.3. Please review draft-ietf-tls-mldsa [1] and reply to this
>>> thread indicating if you think it is ready for publication or
>>> not. If you do not think it is ready please indicate why. This
>>> call will end on April 23, 2026.
>>> 
>> 
>> I oppose publication at this time.
>> 
>> Indicating why: - Editorial issues such as "the client MUST treat
>> this a verification failure," should likely be "the client MUST
>> treat this as a verification failure,"; others exist
>> 
> 
> Addressed earlier in the thread.
> 
> 
>> - "mldsa65(0x0905) | ML-DSA-65 | id-ML-DSA-64"
>> 
> 
> Addressed earlier in the thread.
> 
> 
>> - The security consideration section is lacking; it does not 
>> systematically address concerns raised about non-hybrid
>> cryptographic deployments
>> 
> 
> Addressed earlier in the thread.
> 
> 
>> - The draft does not suitably address the security needs of
>> environments where hybrids are recommended or required
>> 
> 
> Addressed earlier in the thread.
> 
> 
> 
>> A subsequent draft that addresses the above concerns would likely
>> remain inherently risky.
>> 
>> Hybrid signatures are, and remain, a prudent design choice from a
>> risk management perspective. It is nice that many agree on
>> Recommended=N but unfortunately for a casual reader, a
>> recommendation analysis is missing from the security
>> considerations section.
>> 
>> Kind regards, Jacob Appelbaum
>> 
>>> REMINDER: If you have not done so recently, review the TLS WG's
>>> Mail List Procedures; see [2].
>>> 
>>> The Chairs, Deirdre, Joe, and Sean
>>> 
>>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/ [2] 
>>> https://mailarchive.ietf.org/arch/msg/tls/ 
>>> ucdImHExlbOf4Q3BCG81gjzi2xE/
>>> 
>>> _______________________________________________ TLS mailing list
>>> -- [e-mail] To unsubscribe send an email to tls-
>>> [e-mail]
>> 
>> _______________________________________________ TLS mailing list
>> -- [e-mail] To unsubscribe send an email to [e-mail]
>> 
>