Re: New Version Notification for draft-thomson-http-replay-00.txt

On 07/27/2017 06:37 PM, Martin Thomson wrote:
> On 28 July 2017 at 07:01, Willy Tarreau <w@1wt.eu> wrote:
>> It doesn't change the fact that the additional presence of the EarlyData
>> header field added by the client makes no distinction here, it's just
>> redundant with the connection using 0-RTT.
> This is the core of the issue.  And this statement is true.  If the
> data arrives in early data - and that can be detected reliably by a
> recipient - then the header field doesn't add any value.

Yes, that statement is true.

> The point on which we seem to be disagreeing is whether it is better
> to increase the reliability of the signal (by mandating use of
> Early-Data by clients), or to insist that server (or serving
> intermediary) implementations are careful in determining whether a
> request arrived in (or partially in) early data.

Sure.  And I think some of the viewpoints have been driven by existing
implementations that only offer a "is the handshake finished?" API where
it's harder to tell "did any part of this request come in over early data?".

> The key advantage of NOT mandating Early-Data is that it enables a
> strategy of waiting.  An absent header field means that this is the
> first hop to use early data.  Mandating use of the header field means
> that a server cannot know whether there was a previous hop that used
> early data and so it cannot wait for the client Finished (that
> previous hop might not have completed correctly).

(No comments on the "increment the number in the Early-Data header on
each hop" strawman yet?)

> The key advantage of mandating Early-Data is that it improves the
> signal.  But it removes the waiting option from consideration (that's
> a bug in my PR).
>
> After some consideration, I'm somewhat more inclined to side with
> Willy on this particular issue.  Mainly for the performance advantage,
> but also because it makes the default implementation easier (no
> modification of header fields on retry).  I will acknowledge that it

I'm certainly willing to be part of a consensus that allows the waiting
option...

> makes server implementations more difficult; a lot more hinges on
> whether the server is able to reliably detect that a request was
> received in early data.

... but we'll need to make sure that TLS stacks provide useful APIs for
servers to be able to do this.

Just to be clear, we're ending up in a space that allows waiting for the
first hop, but requires subsequent hops to send the 4NN if any part of
the request came in over early data, is that correct?  (That is,
later-than-the-first hops do not have the option of waiting for
ClientFinished.)

> The requirement to treat requests consistently is something we should
> retain no matter what the outcome of this discussion is.

Yay!

More replies to Willy's previous mail separately, though I don't think
they affect the question at hand.

-Ben