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

On 28 July 2017 at 22:58, Benjamin Kaduk <bkaduk@akamai.com> wrote:
>> 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?".

That might be the case.  The perception that this API thing is some
sort of fundamental disagreement is odd.  You might yet convince me
that we need something, at least on the server side.

I have been convinced that a server application needs greater
certainty than the simple "handshake is finished" signal.  We might
actually have that certainty, but I want to double-check.  I need to
do some investigation on our implementation before I comment more, but
I'll get back to you on this.

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

That might work.  If our model includes participants in hops that
understand early data that always increment the value (both on the
send and receive side).  The only place where it won't increment is if
an intermediary doesn't understand Early-Data, but that's OK because
they won't be using it.

>> 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.)

That would be the plan.  The only gotcha being whether we can have a
reliable signal to the server.

Received on Monday, 31 July 2017 00:08:15 UTC