[TLS] Re: PQC Continuity draft

[Eric Rescorla <[e-mail]>]

On Mon, Feb 9, 2026 at 7:20 AM Scott Fluhrer (sfluhrer) <[e-mail]>
wrote:

>
> And, assumption (3) asks whether we have any responsibility for the
> 'unwashed masses', that is, the people who aren't security experts.  Well,
> yes, I would claim that we do.  Those people are relying on us to protect
> them (so that they can spend their time on the areas they are experts in).
> I believe that we have a responsibility for those who depend on us, just as
> we rely on other aspects (e.g. DNS, routing) that we assume 'just work'.
>

Without taking a position on the merits of this idea generally, I would
like to observe
that it's not generally the case that people are individually deciding
whether to trust
non-PQ credentials or not. Rather, their software provider--in the Web
case, the
browser vendor--makes a global policy decision for their product. In some
cases,
users can of course change their configurations, but they generally don't.

-Ekr

------------------------------
>
> *From:* Felix Linker <[e-mail]>
> *Sent:* Monday, February 9, 2026 6:02 AM
> *To:* Eric Rescorla <[e-mail]>
> *Cc:* TLS WG <[e-mail]>
> *Subject:* [TLS] Re: PQC Continuity draft
>
> Hi everyone,
>
> I'm doubtful whether this draft can actually enhance security of TLS
> connections. I think this draft relies on three assumptions (eventually
> holding). (1) CRQCs exist, (2) the world is somehow oblivious to this and
> PQ-certs are not widely deployed, and (3) we want to protect "the masses,"
> not security-sensitive individuals.
>
> If not (1): No downgrade attack possible without compromising server key
> material (which might as well be PQ-key material).
> If not (2): Every client could refuse non-PQ-secure connections.
> If not (3): Security-sensitive individuals could enforce PQ-secure
> connections (potentially on a per-server basis, when they're concerned
> about specific connections; effectively out-of-band pinning).
>
> Supporting legacy clients cannot really be the concern. It seems more
> relevant how many servers can be expected to support PQC. If servers
> overwhelmingly support PQC, the adversary could try MITM-ing sessions by
> pretending that a client does not support PQC, but the honest client
> supporting PQC would abort that connection as they see it be non-PQ-secure.
> The client not supporting PQC is screwed anyway.
>
> Additionally, I think this draft can only work if the "failure case"
> (abort connection) is infrequent and correlates with an attack taking
> place. If there are too many false positives, adoption might drop
> significantly. It seems intuitive to me that this may not be the case, and
> that policy violations rather lead to aborted connections because of
> misconfiguration (especially factoring in operational feedback mentioned
> earlier).
>
> Also, I'm doubtful that assumption (2) will be the case. Wouldn't it be
> the preferred way forward to enforce PQ algorithms and eventually treat
> non-PQ-connections as insecure?
>
> Best,
> Felix
>
>
> Am Sa., 7. Feb. 2026 um 22:20 Uhr schrieb Eric Rescorla <[e-mail]>:
>
>
>
> On Sat, Feb 7, 2026 at 1:12 PM Muhammad Usama Sardar <
> [e-mail]> wrote:
>
> On 07.02.26 21:07, Eric Rescorla wrote:
>
> However, if the client successfully
> connects to the server once with the PQ algorithm, then the client can
> remember
> that and in future insist on the server using P and thus prevent this kind
> of attack.
>
> [I don't have a PQ model yet, this is just my intuition which may be
> completely wrong] What I am failing to see is how remembering is better
> than a simple solution: If the client is already convinced that traditional
> signature algorithm T is weak and it only wants PQ signature algorithm P,
> then it should simply not offer T in ClientHello.
>
> The setting of interest is one where there is a large fraction of servers
> which do
> not support PQ algorithms. In this case, any client which rejects T will
> effectively
> be unable to communicate with those servers. This might be desirable if
> CRQCs
> are ubiquitous and attacks are cheap, but what about the case where CRQCs
> are
> very expensive or where it's unknown whether a CRQC even exists. In this
> case,
> it might be desirable to have clients insist on PQ algorithms for servers
> it knows
> support them, but fall back to non-PQ algorithms otherwise.
>
> You might find this post useful, as it goes into the situation in some
> more detail:
> https://educatedguesswork.org/posts/pq-emergency/#signature-algorithms
>
> -Ekr
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>