On Thu, Dec 3, 2020 at 1:16 PM Eric Rescorla <e...@rtfm.com> wrote: > If a client certificate has been associated with the session, the > client MUST use the same policy on whether to present said > certificate to the server as if it were a new TLS session. For > instance, if the client would show a certificate choice prompt for > every individual domain it connects to, it MUST show that prompt for > the new host when performing cross-domain resumption. > > This seems like it only applies with post-handshake auth, right, given > that you can't do resumption + client auth. >
I'm not sure if it's ever been written down anywhere (probably should be...), but I think resumption is pretty much universally interpreted as authenticating as the identities presented over the original connection, client and server. That means that, independent of this draft, the client should only offer a session if it is okay with both accepting the original server identity, and presenting the original client identity. (Analogously, HTTP connection reuse reuses TLS handshake-level decisions, so you have to be okay with that decision to reuse the connection.) It's common to key client certificate preferences by server domain, so this text is saying you should offer cross-domain sessions consistent with that. (Analogously, HTTP/2 cross-domain connection reuse has the same effect and you have to be okay with that decision. In Chrome, we don't do cross-domain connection reuse on connections with a client certificate, since the user was only prompted for the original domain. I expect we'd apply a similar rule to resumption.) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
