[TLS] Re: Complaint to ADs and IESG regarding TLS WG chairs falsely claiming WG consensus to issue an RFC for draft-ietf-tls-mldsa

[Eric Rescorla <[e-mail]>]

ISTM that there are two distinct questions:

1. What is the risk now of continuing to use pure classical algorithms?
2. What is the risk of switching to pure PQ algorithms instead of
   hybrids?

The first question helps us assess the urgency of a transition to PQ.
The second, whether we should deploy hybrids instead of pure PQ.

As far as the first question goes, as Watson says, pure classical
algorithms are only risky if the attacker has a CRQC at the time of
(or more properly, prior to) the attack. Moreover, this risk exists as
long as the relying party will accept a classical algorithm.  Due to
the inferior bandwidth properties of the PQ algorithms, many if not
most uses of TLS are unlikely to switch off support for classical
algorithms until there is stronger evidence of a probable CRQC. [0] As
a result, partially transitioning to support of PQ algorithms doesn't
help much, because the attacker can still attack traditional
credentials [1]. Rather, it's really about setting us up for a
transition to PQ-only if/when we have to.

This brings us to the second question: suppose that we start by
deploying some PQ algorithm (whether hybrid or pure). Once RPs accept
it, then any weakness in that algorithm becomes a weakness in the
system even if an individual endpoint only has a classical
credential. For example, if clients will accept pure MLDSA and there
is a classical attack on MLDSA, then an attacker can mount an
impersonation attack on any server, regardless of what credential it
actually has.

The argument for hybrids in this context is that if if one has
substantially higher confidence in the security of the traditional
algorithm than the PQ one against classical attack, than it is safer
to deploy hybrids. As as been discussed in detail, however, the threat
model is different here because the attacker has to be able to break
the vulnerable algorithm at the time of the connection (this is just a
generalization of Watson's point), so the level of risk depends on (a)
how rapidly you can disable the PQ algorithm if it's found to be
vulnerable and (b) how likely you think it is that there will be a
secret compromise the PQ algorithm so you don't know to disable it.
You have to make this assessment on your own, but it's a distinct
situation from HNDL, where there is action you can take to protect
already-transmitted data.

-Ekr


[0] This may be different for systems such as SSH where the keys are
often not authenticated via a global PKI and therefore it's possible
for individual endpoint pairs to disable PQ safely.

[1] See
https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/
for a more in-depth discussion of the issues here.


On Wed, May 27, 2026 at 2:19 PM Nico Williams <[e-mail]> wrote:

> On Wed, May 27, 2026 at 02:11:16PM -0700, Watson Ladd wrote:
> > On Wed, May 27, 2026 at 2:08 PM Nico Williams <[e-mail]>
> wrote:
> > >
> > > On Wed, May 27, 2026 at 02:01:08PM -0700, Watson Ladd wrote:
> > > > On Wed, May 27, 2026, 1:48 PM Simon Josefsson <simon=
> > > > [e-mail]> wrote:
> > > > > Repeating that statement doesn't make it true.  The analog
> motivation
> > > > > for doing PQ hybrids is Man-In-The-Middle attacks.  If your
> non-hybrid
> > > > > PQ signature has a weakness (e.g., implementation bug), it
> facilitate
> > > > > man-in-the-middle's.
> > > > >
> > > >
> > > > The only way to achieve that is to have a quantum computer at the
> time of
> > > > attack
> > >
> > > Not so.  Find the victim's classical public key (they'll gladly tell
> you
> > > it), use a quantum computer to break it off-line and recover the
> private
> > > key, then use the private key at will to impersonate the victim, then
> > > its counterparties become victims too.
> >
> > Correct: you have to have a quantum computer *before* mounting the
> attack.
> >
> > Or to put another way, todays connections are not compromised by
> > tomorrows computers.
>
> Sure, but today's _credentials_ -if they are still in use 'tomorrow'-
> will be.  Who wants to suddenly have to hurry up and deploy new code and
> change keys all at once on PQ day?  Worse: who wants to be dependent on
> their counterparties to have to do that on PQ day?
>
> But at the same time the same pure-PQC vs. hybrid concerns arise.
> Therefore if we thinkg HNDL justifies hybrid KEMs now then surely MITM
> justifies hybrid signature algorithms now as well.
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>