Re: Early-Data is for intermediaries only

On Fri, Aug 04, 2017 at 11:15:46AM +1000, Martin Thomson wrote:
> 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

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

Received on Friday, 4 August 2017 02:23:37 UTC