Early-Data is for intermediaries only

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

Received on Friday, 4 August 2017 01:16:39 UTC