On Mon, Feb 9, 2026 at 7:20 AM Scott Fluhrer (sfluhrer) <[email protected]> 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 <[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]
