On Thu, Feb 5, 2026 at 7:23 AM Yaron Sheffer <[email protected]> wrote:
> Below. > > *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. -Ekr [1] The SHOULD is a bit confusing, because it implies you could just offer Y and not X, which is plainly bad. If you're going to do this at all as a client, then you MUST do X.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
