Hey Scott, I totally agree with your note on (3).
On (1): The negation of (1) is not that CRQCs never exist, but that they don't exist right now. When people start being concerned about their existence, the alternative to this draft would be to treat legacy certificates as insecure and thus invalid (which is what they would be). Which option is preferable? My gut feeling is treating legacy certificates as invalid. It seems cheaper and simpler to deploy and would force servers to migrate. And it would not deny access to unmaintained parts of the Internet. You could still proceed to connect insecurely (as you can today with certificate errors). Now, this could backfire if assumption (2) applies. The failure case would be the norm, and people would likely just ignore the error and move on to connect insecurely. I really don't know how realistic assumption (2) is. Cloudflare was at ~50% PQ-support (though, not against active PQ attackers) last October (see https://blog.cloudflare.com/pq-2025/). Is Cloudflare the norm or the outlier? I don't know. But to me, this seems like the critical point to discuss. Best, Felix Am Mo., 9. Feb. 2026 um 16:20 Uhr schrieb Scott Fluhrer (sfluhrer) < [email protected]>: > I would like to disagree with Felix's conclusions. > > As for his three assumptions, I can't disagree with (1); if CRQCs never > exist, this is largely a nonissue (I'm not particularly worried about > classical attacks against large RSA keys). However, I don't believe that > 'a CRQC will never exist' is a prudent security assumption. > > Assumption (2) appears to assume that the certificates on the entire > internet can easily be updated to all be postquantum. That is, there won't > be an old server out there with only classical certificates, or if there > is, we don't mind denying access to them. Given the number of largely > unmaintained servers out there in the world, I personally find that > implausible. Remember how long it took before we got rid of the old > certificates with MD5 or SHA-1 based signatures? > > 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'. > > Felix also raising the point of failures. I can think of two nonattack > scenarios where an abort connection may happen: > > > - The web site has multiple servers (with DNS records pointing to the > various servers to do load distribution), and some of the servers have PQ > certs and some don't. > - The server was upgraded to a PQ cert, and then that cert was > deliberately backed out for some reason. > > > Both of those are possible, but (IMHO) fairly rare; section 3.5 of the > draft discusses (but not totally mitigates) the second scenario - further > discussion in the draft may be warranted. > > > ------------------------------ > *From:* Felix Linker <[email protected]> > *Sent:* Monday, February 9, 2026 6:02 AM > *To:* Eric Rescorla <[email protected]> > *Cc:* TLS WG <[email protected]> > *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 <[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]
