Subject: [TLS] Adoption call for draft-sy-tls-resumption-group

From: "Christopher Wood" <[email-masked]>
Date: Fri, 12 Apr 2019 19:33:51 -0400

At TLS@IETF104, there was interest in the room to adopt draft-sy-tls-resumption-group as a WG item. The draft can be found here:

    https://datatracker.ietf.org/doc/draft-sy-tls-resumption-group/

This email starts the call for adoption. It will run until April 26, 2019. Please indicate whether or not you would like to see this draft 
adopted.

Thanks,
Chris, Joe, and Sean

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 13 Apr 2019 00:10:01 -0400

I like the basic idea, but I don't think that this is the right solution.  I realize that we can adopt and fix, but I my preference is to have a little more time to discuss solutions before we adopt anything.

On Sat, Apr 13, 2019, at 09:35, Christopher Wood wrote:
> At TLS@IETF104, there was interest in the room to adopt 
> draft-sy-tls-resumption-group as a WG item. The draft can be found here:
> 
> This email starts the call for adoption. It will run until April 26, 
> 2019. Please indicate whether or not you would like to see this draft 
> adopted.
> 
> Thanks,
> Chris, Joe, and Sean
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Erik Sy <[email-masked]>
Date: Tue, 16 Apr 2019 10:35:52 +0200

Hi Martin,

can you please explain, why you think this is not the right solution?

To start the discussion, I provide below some insights on why I ended up
with this solution.

Question 1: Shall the problem be solved by a cross-layer solution or by
a TLS-only approach?

Arguments for a TLS-only approach:
+ It is simpler to solve the problem within TLS
+ TLS resumptions across SNI values are available for every use case of TLS
+ So far, there does not exist a mechanism in another protocol which can
be directly used to indicate feasible session resumptions across SNI values

Arguments for a cross-layer solution:
+ Context information of other protocols such as HTTP and IP can be used
to fine-tune resumptions across SNI values

Question 2: Shall the TLS resumption group be defined as a separate list
provided by the server or cover the entire SAN list of the certificate?
Note, that it is a strict requirement that resumptions across SNI values
are only conducted if the involved SNI values are valid for the server
certificate presented during the initial connection establishment.

Arguments for a separate list:
+ Flexibility, to define the resumption group without some entries of
the SAN list

Arguments for defining the resumption group as the entire SAN list:
+ smaller overhead in terms of data traffic
+ Simpler and hopefully avoids new security errors that implementations
allow to conduct session resumptions to illegitimate SNI values

Finally, I ended up with a TLS-only approach using the entire SAN list a
resumption group. However, I do not claim that the provided lists of
arguments are complete and would like to encourage you to contribute to
this list.

Thanks,
Erik

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 24 Apr 2019 03:36:45 -0400

> can you please explain, why you think this is not the right solution?

To recap, the draft proposes an empty extension in ClientHello, which the server, at its discretion, includes in Certificate.

There are two insights that are important here:

1. The client could, if it chose, send any session ticket from any server to any other server[1].  The reasons for not doing that are primarily linkability: by using a session ticket it links the connection where it is used with the connection where it was acquired.

2. The linkability thing means that clients can't reuse session tickets because that changes the set of entities that can link sessions from (issuer+consumer) to (issuer+consumer+network path).  This is what leads us to strongly recommend using tickets at most once.

The second observation is what drives the signal.  We want to have a signal so that the client can make the resumption attempt without wasting the ticket on a server that simply cannot use it.

I think that the signal could be attached to NewSessionTicket instead:

   The server MAY also send unsolicited extensions
   in the NewSessionTicket, though the client does not respond directly
   to these.

[1] What it means to resume with a completely different server identity, where the client has seen no previous authentication, is a separable question.  And I don't think that the current draft goes far enough to address this complex question.  It currently says:

   This resumption group is formed of all SNI values
   that are valid for the presented server certificate.

That is convenient and probably ultimately a good baseline for this, but it doesn't capture some of the things we learned about the scope of server authority out of HTTP/2 and the ensuing work.  I think that this needs to transition - at least conceptually - into the application layer and rely on the client's understanding of what identities the server holds.  

I'm OK with adoption without addressing that concern, but it does need to be addressed.

Finally, there is some text in the draft that I think needs to be removed.  For example, the normative text on cache lifetime here:

   According to [RFC8446], clients MUST NOT cache tickets longer than
   seven days.

   Note, that TLS resumption enables a server to link resumed
   connections to the same client.  A study on the feasibility of this
   tracking mechanism can be found in [TRAC].  To protect the client's
   privacy against tracking via this mechanism, it is RECOMMENDED to
   cache resumption tickets only for ten minutes.

...or this:

   To optimize the performance benefit of this extension, the server's
   certificate is RECOMMENDED to only include SNI values that mutually
   support the resumption of their TLS connections. 

There's enough there that I think that another iteration would be wise before adoption, that's all.

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 26 Apr 2019 02:45:49 -0400

Hello everyone,

I believe that the problem this draft addresses is important, and I believe
the working group should take on this work.

For various operational reasons, websites often use different IPs for
different resources they need to fetch.  Resumption across different SNI
values could allow them to use 0-RTT, reducing penalty for new connections
they have to make.

A particular case I want to address is a situation when there is a CDN (say
cdn.example.com) that has multiple shards (say shard101.cdn.example.com and
shard102.cdn.example.com), and the client gets load balanced to a specific
shard based on requested resource.  In the current situation, unless
shard101 and shard102 share the same physical IP, they'd have to pay
connection startup cost for each request.  Cross-domain resumption would
allow 0-RTT to the second shard accessed, provided all shards have a
wildcard certificate.

>From the technical standpoint, I agree with Martin that a NewSessionTicket
extension would be a better fit, but this is something that we can figure
out later without much trouble.

The policy questions (when *should* the client resume?) are more difficult
here, and there are multiple aspects to this.  One is, as Martin pointed
out, is clarifying the notion of server identity from application
perspective in cross-domain scenario.  Another is ensuring that the
linkability properties are not altered in ways we don't understand.  On the
surface, one can argue that this is semantically the same procedure as
HTTP/2 connection pooling, but without the IP match requirement.  This is
good, because we can build on the analysis of an existing mechanism.
Still, in practice, this might open us up to attacks that with the IP match
were impractical.  We should ensure that the document describes things
we've learned from connection pooling, too.

As I've said before, I am happy to help with this draft.

  -- Victor.

On Fri, Apr 12, 2019 at 7:36 PM Christopher Wood <[email-masked]>
wrote:

> This email starts the call for adoption. It will run until April 26, 2019.
> Please indicate whether or not you would like to see this draft
> adopted.
>
> Thanks,
> Chris, Joe, and Sean
>

---

From: Erik Sy <[email-masked]>
Date: Fri, 26 Apr 2019 11:29:56 +0200

On 4/26/19 08:45, Victor Vasiliev wrote:
>
> From the technical standpoint, I agree with Martin that a
> NewSessionTicket extension would be a better fit, but this is
> something that we can figure out later without much trouble.
I agree with Martin and Victor, that the NewSessionTicket extension is
the better fit to signal support for this TLS extension.
>
> The policy questions (when /should/ the client resume?) are more
> difficult here, and there are multiple aspects to this.  One is, as
> Martin pointed out, is clarifying the notion of server identity from
> application perspective in cross-domain scenario.  Another is ensuring
> that the linkability properties are not altered in ways we don't
> understand.  On the surface, one can argue that this is semantically
> the same procedure as HTTP/2 connection pooling, but without the IP
> match requirement.  This is good, because we can build on the analysis
> of an existing mechanism.  Still, in practice, this might open us up
> to attacks that with the IP match were impractical.  We should ensure
> that the document describes things we've learned from connection
> pooling, too.
>
I agree, that the new feature of this extension for web browsing is to
conduct HTTP/2 connection pooling without the IP match requirement.
However, we should consider a network attacker to be anyway in control
of DNS. Thus, the requirement of a matching IP does not provide security
benefits against this attacker.

As learnings from connection pooling I'm aware of origin confusion
attacks against virtual hosting. Can somebody point out other relevant
attacks in this context?

Best,
Erik

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 29 Apr 2019 12:24:27 -0400

The adoption call for this document is finished. Due to the lack of comments and some concern raised over the existing design, the chairs feel the draft needs more discussion and possible revision(s) before the WG adopts this as an active work item. 

Best,
Chris, Joe, and Sean