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

[Jacob Appelbaum <[e-mail]>]

Hi Bas,

On 4/28/26 15:20, Bas Westerbaan wrote:
>> If that is still wrong,
> 
> 
> Why do we use server certificates in TLS? To prevent impersonation of the
> server. If you never talk to the intended server, then it doesn't matter
> which certificates your server has installed. To wit: your server might not
> have any quantum vulnerable certificates installed, but if a visitor
> accepts a quantum vulnerable root, then any quantum attacker (come Q-day)
> can impersonate your server.

Your example makes sense to me. The same basic reasoning applies to a 
root where the new PQ signatures are broken by a regular computer before 
Q-day. Both attacks may apply but with one of them the attacker may not 
require a quantum computer. Don't we want to stop _both_ kinds of 
attackers? Why shouldn't this tension be clearly documented in the 
security considerations of the draft?

I take that as you agreeing that my summary of the TLS protocol was 
otherwise correct and that I did not misunderstand TLS?

We obviously have a disagreement of scope rather than a misunderstanding 
of the protocol steps. The disconnect seems to be a matter of a narrower 
vs a wider perspective. My view remains that a client in the very near 
future should not accept Rad in place of Trad, only PQ/T as an addition 
to the Trad ECC cryptography. Today many only accept Trad ECC, and 
ideally soon we should see PQ/T cryptography all the way up to the root.

The draft could set that as the baseline because it is the safest option 
that covers the largest number of attacks. I understood that you agreed 
on the list about hybrids but without documenting it in the draft. If 
you don't agree about hybrids then that is the core of the disagreement. 
If we are in agreement, the missing part is the analysis, and that 
agreed upon conclusion being added to the draft.

> 
> 
> I do not think the draft currently addresses the security-section point
> 
> I am raising: why a non-hybrid PQ signature is an acceptable
>> authentication baseline when hybrid/PQ-T constructions are the more
>> cautious baseline for key establishment and signatures. It is my
>> understanding that you generally agree and yet this agreement is not
>> reflected in the draft.
>>
> 
> This draft does not recommend ML-DSA-44 as a baseline. Feel free to suggest
> a wording you like better and that reaches rough consensus in this working
> group.
> 

Before and after the introduction of this draft, what then would be the 
baseline for PQ crypto in TLS in your view?

In any case, here's my first draft of a suggestion for the security 
considerations as you requested:

"The IETF is not recommending the use of post-quantum cryptography as 
defined in this document. The use of ML-DSA as with ML-KEM in TLS 
without a PQ/T or hybrid construction is a matter of serious contention 
as post-quantum cryptography alone does not provide the desired security 
offered by hybrid constructions. This document is MUST NOT be intended 
to be used as a transition document. This document MUST NOT be used to 
justify further post-quantum cryptography deployments or the use of 
post-quantum cryptography in non-hybrid constructions. ML-DSA alone as 
defined in this document MUST NOT be used at this time."

There are no protocol police, so people will do whatever they feel like 
doing. It will however clearly be their responsibility for making a 
risky decision. A lack of doing this earlier is why we see PQ rather 
than PQ/T being advanced using the previous risky advance as a basis for 
future risky advances. Most but not all of my concerns would be 
addressed by surfacing both the points of agreement and the points of 
disagreement to all readers. I don't feel strongly about the wording and 
I don't speak for others but I do think that this at least reflects many 
of the concerns raised.

Kind regards,
Jacob Appelbaum