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 <[email protected]>: > > > On Sat, Feb 7, 2026 at 1:12 PM Muhammad Usama Sardar < > [email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
