Subject: [TLS] draft-sy-tls-resumption-group comments

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Mar 2019 05:21:06 -0400

This is quite an interesting idea, and it's good to see a draft starting the discussion.

I have some interest in this general problem space, but am concerned that this proposal is operating at the wrong layer of the stack.  It's a fairly obvious design, given that TLS provides the NewSessionTicket message, but that isn't the only relevant consideration.

In doing connection coalescing in HTTP/2, we discovered that there are many cases where servers have certificates for a wider span of names than they are truly able to serve.  You can connect to foo.example.com, which has a wildcard certificate for *.example.com, but while it might happily serve bar.example.com or other names, it is completely incapable of serving other names (e.g., baz.example.com might be operated by a completely different provider).

We sort of knew that already, which is why we added the 421 status code in RFC 7540, but RFC 8336 (ORIGIN frame) was needed to provide a better fix. The insight there is that for names other than the one for which the connection was made, the server needs an explicit opt in to having those names/origins used on the same connection.  [1]

The same will apply to resumption and so similar mechanisms are likely necessary for this to be useful for HTTP.  Re-building those at the TLS layer will be costly.

Any design needs to be really crisp about the scope of applicability here.  Is it possible to connect to port 443 and then use the same ticket when connecting to port 465?  I doubt that.  It might make sense to constrain this by protocol (or ALPN) at least to avoid problems, but it probably needs to include port numbers as well.  This is why the ORIGIN frame uses origins, which conveniently encapsulates the key ideas.  Origin uses scheme and not ALPN, which is important in that context, but for this example, the narrower concept of ALPN is likely to be necessary.

Finally for HTTP (and likely other protocols) the cross-site tracking characteristics of this design are interesting.  This is a form of cookie that origin X can set and origin Y can read outside of the usual paths.  I don't know if we could reasonably implement this in a web browser.

Cheers,
Martin

---

From: Erik Sy <[email-masked]>
Date: Wed, 20 Mar 2019 15:53:01 +0100

Dear Martin,

thanks for reading the draft and commenting on it.

You point out, that there exist similarities between the draft and
connection coalescing in HTTP/2 and a solution in HTTP can somehow solve
the described performance problem.

As I understand it, connection coalescing in HTTP/2 is improving
performance by reducing the number of required connections. However,
this draft proposes a mechanism to optimize the process of resumed
connection establishment. Thus, in case that a connection cannot be
avoided via connection coalescing, this draft may contribute to an
efficient connection establishment. I think both approaches should be
pursued independently and that the TLS layer is the right place to
improve the TLS connection establishment.

Furthermore, you mention that we need something similar to RFC 8336
(Origin HTTP/2 frame) to explicitly opt-in for session resumptions
across SNI values and that this might lead to significant complexity.

I agree, that an explicit opt-in is required. As described in the draft,
the server indicates support for session resumptions across SNI values
with a single bit. If this bit signals support for this feature, then
the subject alternative name (SAN) extension of the certificate is used
to define the resumption group, which members mutually accept their TLS
resumption tickets to establish resumed connections. I hope this
description mitigates your concerns.

Moreover, you point out issues with the scope of applicability. The
proposed behavior would use the same ALPN parameter as associated with
the PSK in use when resuming a connection across SNI values. If this
used ALPN parameter is not accepted by the server when establishing a
resumed connection, we apply the fallback as defined in TLS 1.3 for
standard session resumptions. Does this solve your issue?

Finally, you address cross-site tracking enabled by this design. I
discussed this point in a subsection of
https://arxiv.org/pdf/1902.02531.pdf.
Generally spoken, I think it is not feasible to defend against
cross-site tracking if two sites collaborate with each other. For
example, a simple redirect from site A to site B can be used to link the
logs on a user across both sites. Thus, this proposal does not increase
the privacy risks of web browsing. However, browser vendors should
implement proper countermeasures against long-term tracking via session
resumption mechanisms (see https://arxiv.org/pdf/1810.07304.pdf).

Best,
Erik

On 3/20/19 10:21, Martin Thomson wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls