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: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 11 May 2017 10:19:58 +0200
Cc: Mark Nottingham <mnot@mnot.net>, Erik Nygren <erik@nygren.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Ponec, Miroslav" <mponec@akamai.com>, "Kaduk, Ben" <bkaduk@akamai.com>
Message-Id: <C28E2CB2-5F28-4853-8DDD-2EF5705878D7@greenbytes.de>
To: Willy Tarreau <w@1wt.eu>

> Am 11.05.2017 um 07:33 schrieb Willy Tarreau <w@1wt.eu>:
> 
> Hi Mark,
> 
> On Thu, May 11, 2017 at 10:23:12AM +1000, Mark Nottingham wrote:
>> 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...
> 
> That's exactly the situation I'm facing for now with haproxy. A few
> users have asked us to support 0RTT and by lack of way to 1) decide
> which requests are really safe, and 2) tell the client it must replay
> them using 1RTT, for now I refused to enable it. The load balancer
> and the origin server will have a different view of the acceptability
> of 0RTT, and all the chain must be able to accept or reject them, and
> let the client retry.

Even the "origin server" might not be aware what the application's
committal and guarantee here is. 

My thoughts for an implementation is:

- it has to work without the "upper" layer / next hop being aware of it
- it has to fail in a defined HTTP way. The HTTP request is tagged as
  possibly replayed, regardless of the actual transport. The answer
  needs to also work on that transport.
- The negative answer to a 0-RTT request might come early, might come
  late. For h2, other streams might have been opened, even answered,
  in the meantime.
- The sender selecting 0-RTT should only do so, if it understands the
  retry answer. (Once that is defined)
- The sender may well want to select 0-RTT only if it considers the
  data to be safe for replays *and* it expects the server to come to
  the same conclusion.
- So, ideally, sender and receiver have the same notion about what HTTP 
  data is acceptable for 0-RTT.

-Stefan

> 
> I tend to think that a 4xx status code would make sense and would be
> useful to pass the verdict back to the client. For example we could
> return "418 not idempotent".
> 
> Willy
> 
Received on Thursday, 11 May 2017 08:20:33 UTC

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