On Thu, Dec 3, 2020 at 11:12 AM David Benjamin <david...@chromium.org> wrote:
> 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.) > Yes, this seems reasonable, but I didn't get it from the text, so maybe if this is adopted we could file an issue. -Ekr David >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
