[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]>]

Just for the record, this message is about signature algorithms...

On Wed, May 27, 2026 at 2:27 PM Eric Rescorla <[e-mail]> wrote:

>
> 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]
>>
>