Re: Early-Data is for intermediaries only

Hi Martin,

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

2017-08-04 10:15 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> 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
>



-- 
Kazuho Oku

Received on Friday, 4 August 2017 02:41:07 UTC