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

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Dec 2020 13:49:25 +0000

I support the draft and will review.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Dec 2020 10:14:42 -0800

Document: draft-vvv-tls-cross-sni-resumption-00.txt

I think we should adopt this draft. Some review comments below.

S 1.
   Section 4.2.11).  However, in the absence of additional signals, it
   discourages using a session ticket when the SNI value does not match
   ([RFC8446], Section 4.6.1), as there is normally no reason to assume
   that all servers sharing the same certificate would also share the
   same session keys.  The extension defined in this document allows the
   server to provide such a signal in-band.

"session keys" is a weird term here. Perhaps "same session cache"?

S 3.
   The server MAY send the extension if it reasonably believes that any
   server for any identity presented in its certificate would be capable
   of accepting that ticket.  The server SHOULD NOT send the extension
   otherwise, since, if the client follows the single-use ticket policy
   recommended by [RFC8446], sending the ticket results in it being no
   longer usable regardless of whether resumption has succeeded.

Would a MUST be cleaner here? "Reasonably believes" is already pretty
weak.

I think we should say you can't use this with 1.2, even though it's
kind of obvious.

 S 4.
 It seems like a cite to https://www.mitls.org/downloads/vhost_confusion.pdf
 and an explanation of any impact this mechanism has would be in order
 here.

   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.

-Ekr

On Tue, Dec 1, 2020 at 5:49 AM Salz, Rich <rsalz=[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: David Benjamin <[email-masked]>
Date: Thu, 3 Dec 2020 14:12:08 -0500

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Dec 2020 12:05:13 -0800

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

> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Dec 2020 20:44:05 +0000

*    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.)

Totally agree.  @ekr, you want to make this change in your BIS draft?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Dec 2020 12:59:40 -0800

Hmmm... I think it probably goes in this draft, but I'm open to being wrong.

On Thu, Dec 3, 2020 at 12:46 PM Salz, Rich <[email-masked]> wrote:

>
>    -  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.)
>
>
>

---

From: David Benjamin <[email-masked]>
Date: Thu, 3 Dec 2020 16:07:43 -0500

I think, like the tracking issue, it should go in both. (I wrote
https://github.com/tlswg/tls13-spec/pull/1205 to try to capture the
tracking case.) This draft should definitely (re)-state it because TLS
preferences are most common keyed by domain name. So even if it's in TLS
itself, it's worth emphasizing it.

At the same time, I think it is a general property of resumption. An
application may have different TLS preferences even for a single domain.
(E.g. web browsers make both credentialed and uncredentialed requests,
which are supposed to imply different client certificate preferences.) Or
maybe you have some contexts with different server authentication
preferences than other contexts. Such an application would need to adjust
its resumption behavior accordingly.

To me, the ideal state would be that TLS contains the long-form general
guidance and then this draft cites TLS as a reminder, because keying
preferences by domain is so common. But since the order between rfc8446bis
and this draft isn't yet clear, probably we restate the rules in full in
both and, after rfc8446bis is done, documents can be more concise.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Dec 2020 21:48:45 +0000

*   Hmmm... I think it probably goes in this draft, but I'm open to being wrong.

That’s okay with me.

---

From: David Schinazi <[email-masked]>
Date: Thu, 3 Dec 2020 16:17:52 -0800

I support adoption of draft-vvv-tls-cross-sni-resumption.

David

On Thu, Dec 3, 2020 at 1:49 PM Salz, Rich <rsalz=[email-masked]>
wrote:

>
>
>    - Hmmm... I think it probably goes in this draft, but I'm open to
>    being wrong.
>
>
>
> That’s okay with me.

---

From: Carrick Bartle <[email-masked]>
Date: Fri, 4 Dec 2020 12:33:22 -0800

I also support adoption.

> On Dec 3, 2020, at 4:17 PM, David Schinazi <[email-masked]> wrote:
> 
> On Thu, Dec 3, 2020 at 1:49 PM Salz, Rich <rsalz=[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Joseph Salowey <[email-masked]>
Date: Sat, 12 Dec 2020 13:31:11 -0800

It looks like there is enough interest in the working group to adopt this
draft.  Authors please submit this as a working group draft:
draft-ietf-tls-cross-sni-resumption-00.

Thanks,

Joe

On Mon, Nov 30, 2020 at 7:20 PM Joseph Salowey <[email-masked]> wrote:

> At this point we do not have many responses and it is not clear if there
> is consensus to adopt the draft.  Given that this call has overlapped with
> vacation time we are going to extend the call until December 11, 2020.
> Please indicate if you are willing to be a reviewer for the draft.
>
> Thanks,
>
> Sean, Chris and Joe
>
> On Mon, Nov 9, 2020 at 7:44 PM Joseph Salowey <[email-masked]> wrote:
>
>> Based on interest and support expressed at IETF 108, this email starts
>> the call for adoption of draft-vvv-tls-cross-sni-resumption. The draft can
>> be found here:
>>
>>
>>    https://tools.ietf.org/html/draft-vvv-tls-cross-sni-resumption-00
>>
>>
>> This adoption call will run until November 30, 2020. Please indicate
>> whether or not you would like to see this draft adopted. Note that this is
>> an adoption call for the draft as a starting point towards solving the
>> problem of resumption across SNI values. The final mechanism may certainly
>> change depending on related efforts, e.g., draft-ietf-tls-tlsflags.
>>
>>
>> Thanks,
>>
>>
>> Sean, Chris and Joe
>>
>