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: Willy Tarreau <w@1wt.eu>
Date: Thu, 11 May 2017 16:38:22 +0200
To: Erik Nygren <erik@nygren.org>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Kazuho Oku <kazuhooku@gmail.com>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Ponec, Miroslav" <mponec@akamai.com>, "Kaduk, Ben" <bkaduk@akamai.com>
Message-ID: <20170511143822.GE13597@1wt.eu>
On Thu, May 11, 2017 at 10:21:07AM -0400, Erik Nygren wrote:
> I agree we certainly will need an HTTP status code here and require
> clients that implement sending 0-RTT early data to understand that status
> code
> before sending the early data.   (This may be one reason there's urgency to
> specify
> something soon before clients start implementing without a specification.)

Yes definitely!

> I really like Kazuho's idea for HTTP/2 connections.  There may also be a way
> for H2 proxies to translate between that and status codes.  (ie, if they
> get the HTTP 4xx
> status code from upstream they can make sure that an 1-RTT connection is
> established
> and verified, possibly sending an H2 PING to do so, before resending the
> HTTP request
> as "early data verified by 1RTT handshake".)

For me the H2 ping is mainly a challenge on the connection, equivalent
the RTT achieved by Expect+100 do. On a protocol point of view that's
fine. But I hardly see how to make this thing pass over multiple layers.
You want to validate end-to-end (or at least more than hop-by-hop) and
the ping will only act to the next hop, while the problem caused by
the client and detected by the origin across the LB is still not solved.

> Note that all of this only works for providing safety against replay
> if the decision on when to require 1-RTT is deterministic for a given
> request.

That's why the status code makes it possible to go as far as we want.

Ideally I'd prefer a new Expect: + 100. But that's not doable without
a body. It would look like this :

  client                             server
  ------                             ------
  POST /some-url HTTP/1.1
  Host: some-host
  Expect: replay-safe
                                     HTTP/1.1 418 unsafe try again
                                     HTTP/1.1 100 continue
  ... body ...

On 2.0 we possibly have other options like sending a window update
or priority frame (just thinking), but none of these would easily
address the end-to-end nature of what we want to validate :-/

> For example, doing an H2 PING along with the server_hello and waiting for
> its
> response before processing the request only helps if this will always happen
> for a given early_data request.  The early data can always be replayed so
> just
> because it gets verified by one full 1-RTT handshake doesn't mean that same
> early data can't just get replayed without a 1-RTT handshake by an attacker
> immediately afterwards.

One more reason for asking the client to retransmit everything we decided
is not trusted.

Received on Thursday, 11 May 2017 14:38:57 UTC

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