W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

Re: HTTP profile for TLS 1.3 0-RTT early data?

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 11 May 2017 10:23:12 +1000
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Ponec, Miroslav" <mponec@akamai.com>, "Kaduk, Ben" <bkaduk@akamai.com>
Message-Id: <0000ABB9-E34B-4082-B289-DDB97997CB00@mnot.net>
To: Erik Nygren <erik@nygren.org>
Hi Erik,

> On 11 May 2017, at 7:57 am, Erik Nygren <erik@nygren.org> wrote:
> 
> 
> 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.

[chair hat] Yes. This has been a perennial back-burner topic, and we probably need to move it forward, so we don't block TLS or QUIC.

[personal hat below]


> 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/

... along with concurrent list discussion.

My impression of the outcome there is that HTTP applications that depend on at-most-once delivery have to assure that at the application layer; HTTP provides no such guarantee (even though it implies it with the lack of idempotence for some methods). 

That said, if 0RT mechanisms allow unbounded replays, it might stress (and break) existing application retry protections; my understanding is that the current 0RT proposals do scope replays, however.

Does that seem like where we're at?


> 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.

I wonder if this would be better expressed as a H2/QUIC error code. I also wonder whether it'll be really interoperable; even one client that doesn't implement it correctly (or at all) will be a big disincentive for its use.

If an origin doesn't have robust retry/replay protection in place for non-idempotent requests, it seems operationally simpler and safer for them to disable 0RT, rather than refusing it on a request-by-request basis. That's the discussion I think we should have here...


> 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.)

I'd hope that TLS/QUIC are explicit here, and that we wouldn't need to be; that's the beauty of layered protocols :)


> 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.

Seems reasonable. Then you could Vary on it. *evil grin*

Cheers,



--
Mark Nottingham   https://www.mnot.net/
Received on Thursday, 11 May 2017 00:23:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC