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: > 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 > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
