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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
