Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

[Eric Rescorla <[e-mail]>]

On Thu, Dec 3, 2020 at 11:12 AM David Benjamin <[e-mail]>
wrote:

> On Thu, Dec 3, 2020 at 1:16 PM Eric Rescorla <[e-mail]> 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
>