- From: Erik Nygren <erik@nygren.org>
- Date: Wed, 10 May 2017 17:57:08 -0400
- To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Cc: "Ponec, Miroslav" <mponec@akamai.com>, "Kaduk, Ben" <bkaduk@akamai.com>
- Message-ID: <CAKC-DJjvsYSnENzz2J6RGkA8Kw70yOvnSyq9HT8S5eTxt_zMwA@mail.gmail.com>
Has anyone started working on an I-D for an HTTP (HTTP 1.1 and HTTP/2) profile for TLS 1.3 0-RTT early data usage? We've talked about it briefly in meetings, but it seems like a work area that may need progress soon before people start implementing things differently. This same profile same likely applies to early data for HTTP-over-QUIC as well. Some topics to cover seem to be: 1) What HTTP requests can be safely sent by clients over 0-RTT early data (with the inherent replay-ability and security considerations) ? Mark started some discussion here: https://mnot.github.io/I-D/httpbis-retry/ 2) An HTTP response status code for "Early data not supported for request: retry request with 1-RTT". This will be needed for cases where an HTTP server isn't doing TLS termination and thus may have accepted early data but still want to force the client to always send the request via 1-RTT (eg, for a POST method). This is especially critical if clients and servers make different choices for how to handle #1. This may want some general considerations around how it is better to reject early data during the handshake, but not all server implementations will be able to do this. 3) Being very explicit on how to handle early data that is rejected and forced to be resent following connection establishment (ie, when the server forces a client into 1-RTT mode by rejecting the early data). A worst case would be if a server actually handled the early data anyways but the client thought the server had rejected it. In HTTP/1.1 this could result in them being off-by-one in requests/responses (and could lead to some HTTP Request Smuggling style bugs and vulnerabilities.) 4) Perhaps a general HTTP request header for indicating that requests were received via 0RTT early data (such as Cloudflare's "Cf-0rtt-Unique" header). This would be useful for both load balancers communicating to application servers, as well as for CDNs communicating to origin servers. This would presumably interact with #2 in cases where the appserver or origin wanted to force a client to retry via 1-RTT. 5) ... I'm sure there is more ... Without some agreed on behaviors this could quickly become a mess. For example, if some clients decide to send POSTs via early data while some servers assume clients will never do this and return 403 errors out of paranoia. Best, Erik
Received on Wednesday, 10 May 2017 21:57:42 UTC