On Fri, Feb 6, 2026 at 2:33 PM Muhammad Usama Sardar < [email protected]> wrote:
> That was very insightful. A few clarification questions inline: > On 04.02.26 16:04, Eric Rescorla wrote: > > 2. It allows you to handle the client authentication case as well > > Not sure what "it" refers to. Assuming the proposed *pq_cert_available* > extension, isn't it typically the case that client authentication requires > support of the higher layers (and not done exclusively at TLS layer)? So I > don't see this as benefit, since this might mean you need to change *both* > TLS stack as well as higher layers. > "It" refers to "doing this at the TLS layer rather than the HTTP layer". I don't disagree with you about the need to change the software at both layers; it's just that you wouldn't need to invent a new HTTP-level indicator for the client auth case. 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. > > Is the commitment per connection or per client? Could you explain how does > one infer that? > It's supposed to be per client, but, as you suggest here, the server doesn't necessarily know the client's identity. > [...] I haven't worked through this entirely, but I think the correct > semantics need some fairly close study to avoid creating situations > where one side or another is bricked. > > I believe formal analysis can help here. > Agreed. > the client (usually) knows the server's > identity in advance [...] > > I agree with your overall point on asymmetry but I wonder why do you write > "(usually)"? If the client doesn't know the server's identity, what does it > ask for in the connection? In other words, what are the real-world use > cases when client doesn't know the server's identity in advance? Are there > any such specs? > I don't have a good example to hand, but TLS is a very commonly used protocol, so I was just being cautious. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
