I just had an idea. There is significant doubt of how useful semi-static DHE 0RTT would be due to the difficulty of distributing the configs out-of-bound. I don't dispute this; I merely dispute that no capability is better than minimal, in this realm. There is another way that they could be helpful, however.
Take a typical HTTP page and a client with no prior knowledge. (could be applicable to other applications, but the TLS WG does have a charter to take special note of HTTP latency; subresources' lack of HTTPS often is a stated reason for a site's lack of HTTPS overall) There will be a 1RTT cost without having a pre-cached way to do 0RTT, and then after that there will be a 1RTT cost for *every* subresource on a different server. To do HTTPS for the servers of 3rd party scripts, ads, user-posted images/video embeds, etc., each of those servers will need to be connected to by the client with TLS and no prior knowledge, meaning a 1RTT cost. This could be significantly optimized by creating a new HTTP extension that allows servers to enumerate the domains on a page, cache all those domains' semi-static DHE config, and push them to each client in their first flight returning the primary resource. This would allow all subresources to be fetched by the client with a 0RTT cost, and just a sin gle 1RTT cost for the primary resource. Servers could simply refresh their cache of their subresources' semi-static DHE configs on a daily basis. A stale config can be sent to a client and it can still fallback to 1RTT, though. Clients would not need to have any prior knowledge in order to significantly benefit from 0RTT in this scenario. TLS 1.3 would need to have some way of facilitating this scenario in order to devise a way to do this sort of thing in HTTP (or another general protocol with subresources). The general point I'm trying to convey here is that we can come up with ways to use this to improve latency noticeably, if given the underlying capability. We don't know how effectively it can be used until we try. Dave _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
