On Thu, Feb 5, 2026 at 8:08 AM Yaron Sheffer <[email protected]> wrote:
> *From: *Eric Rescorla <[email protected]> > *Date: *Thursday, 5 February 2026 at 16:16 > *To: *Yaron Sheffer <[email protected]> > *Cc: *TLS WG <[email protected]> > *Subject: *Re: [TLS] PQC Continuity draft > > > > On Thu, Feb 5, 2026 at 5:53 AM Yaron Sheffer <[email protected]> > wrote: > > > Once the server has committed to algorithm X it needs to maintain > algorithm X for the validity period, even if it also supports algorithm > Y. > > > YS: I'm not sure why you're saying that. The draft (and maybe it's not > clear enough) is about the server committing to do PQ in general, not > committing to a particular protocol. > > > That doesn't work mechanically. Once the server has advertised > algorithm X, the client is only required to offer X, which means that > if the server switches to PQ algorithm Y, it is risking a handshake > failure. > > YS: per S. 3.2, "It [the client in this case] MAY include other PQC > signature algorithms, according to local policy." Are you saying that this > is not workable? > > > I'm saying it's not sufficient to provide interoperability > without more restrictions. > > Suppose we have two PQ algorithms, X and Y. Without loss of > generality, the server has a certificate chain using algorithm X. As > described in S 3.2, the client SHOULD include X in its > signature_algorithms, but that it MAY include other PQ algorithms > (e.g., Y). This means that it might *only* include X [0] > > Now, suppose that the server wants to switch to Y. If it does > so within the lifetime of the original advertisement, then it > might encounter a compliant client that only advertises X and > then you get an interop failure. In order for this to work, > the server needs to support X within the lifetime of the advertisement. > > YS: This is all true, but I don't see how it is different from standard > algorithm migration. > In normal algorithmic migration settings, the client would advertise all the algorithms it supports, so the server isn't committing to any particular subset of those algorithms. In this case you are and the draft encourages the client to only *offer* a subset of those, which creates new opportunities for interoperability failures. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
