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

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

Willy

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