Subject: Early-Data is for intermediaries only

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Aug 2017 11:15:46 +1000

I'm going to try to bring the long-running discussions about how to
mark requests to a close.

The point that Subodh brought up relies on confusion about the status
of requests.  If early data is received close to the final handshake
message, the server might be confused about whether the request was
early or not.

Subodh proposed a fix, which was to mark requests with Early-Data at
the client.  This addresses the concern, but increases complexity for
retries and removes some options (and optimizations).

I've put together a PR that captures what I think we have all agreed
to.  The critical point being that servers need to treat all requests
that arrive in early data consistently.

* If you always delay processing until the handshake completes, then
you are safe.  However, this is only possible if we don't mandate use
of Early-Data.  You can't tell whether a previous hop used early data
when the header field is there.

* If you always send 4NN you are safe.  This is only possible if there
is no ambiguity about where the request transitions from 0-RTT to
1-RTT.  You have to use this if the Early-Data header field is
present.

On this last point, I'm going to propose text that mandates making
early data clearly distinguishable in TLS implementations.

I did some investigation in NSS (where we have the single stream API
that is still so controversial).  It is relatively simple to be very
crisp about the various transitions.  It's easy to ensure strict
ordering between delivery of early data, the handshake completion
signal, and the delivery of 1-RTT data.  I did discover a rather
embarrassing bug, but we're in the process of fixing that now.

I've already PR #25, which mandated the use of Early-Data.  The
following PR salvages text that I added about consistent handling, and
expands it a little:

  https://github.com/martinthomson/http-replay/pull/27

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Aug 2017 04:23:12 +0200

>   https://github.com/martinthomson/http-replay/pull/27

Thanks for this excellent summary Martin! I also think that there's a
lot of value in using 0-RTT and that this will put some activity on the
various TLS implementations to ensure that any signal that we need to
make the processing safe will eventually be available.

Willy

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 4 Aug 2017 11:40:42 +0900

Hi Martin,

Thank you very much for the PR. I think that it clearly states how a
server should support 0-RTT data.

-- 
Kazuho Oku