This really only helps on the first connection attempt. Browsers already pre-warm connections to subresource hosts.
On 19 February 2016 at 16:38, Dave Garrett <[email protected]> wrote: > 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 s in > 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 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
