Skip to content

Towards 0 RTT in the client

Marten Seemann edited this page Jan 1, 2017 · 7 revisions

Server Configs

There needs to be a method to store the server configs between two request (or rather two separate connections). I think we could implement a ServerConfigJar, analogous to the CookieJar used in the net/http packet. We need to make sure the CryptoSetupClient correctly handles the case when the server sends a new ServerConfig.

Maybe we could even reuse this for the server in order to store a ServerConfig that would survive a reboot of the server. We could then move to ServerConfigs with a reasonable (maybe application-defined) expiration date.

Replay-safe requests

0-RTT requests are sent with the initial encryption level (i.e. they are not forward-secure). Since they are replaysblr by an attacker, the request MUST be idempotent. While the HTTP specification states that GET requests fulfil that property, this is often not the case in reality (source: e.g. Filippo's and Nick's talk at 33c3). One might want to apply a stricter policy, for example only using 0-RTT for request that don't have GET parameters and / or don't have cookies.

I think the best solution for quic-go is providing a policy callback function func use0RTT(*http.Request) bool that in the QuicRoundTripper to the most restrictive case (no 0-RTT requests at all). The application can then implement its own policy for which kind of request is replay-safe in that specific use case.