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

Greetings!

On 07/30/2017 10:43 PM, Willy Tarreau wrote:
> Hi!
>
> On Mon, Jul 31, 2017 at 10:07:45AM +1000, Martin Thomson wrote:
>>> 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.
> In fact from the various discussions we've had around early data, it
> seems mandatory that an API exposes one way or another the fact that
> *some* such data were replay-unsafe if 0-RTT has to be implemented.
>

I think so, yes.  Expounding on my previous comment about two-party vs.
multi-party interactions, it seems that the HTTP case is qualitatively
different than what we had previously been thinking about in the TLS WG
for an abstract use case.  It seems that we are not just interested in
whether a given TLS message is replayable or is a replay, we rather want
to know whether the contained HTTP message could be replayable in a
global system.  Even if the current TLS message is definitively not
itself a replay (by virtue of ClientFinished validation), that TLS
message might be replayable at a different part of the server farm
(preventable by server implementation), or the TLS message from a
previous hop (containing the same HTTP message) could be replayable, and
that's the part that we don't locally have control over.  So when the
intermediary goes forward, if the message it received was replayable,
then the intermediary must include an indication of that fact, so that
the origin server can send 4NN if the replayability (which in this case
is not controllable locally by the origin server) is unacceptable.

There seem to be two follow-ups from this: (1) if the intermediary knows
that it is part of a system that uses a globally strong replay cache, it
seems like it might still be safe for the intermediary to use 0-RTT
and/or skip the Early-Data header when relaying the request to the
origin.  (But I still want to think about that more.)  (2) It seems that
we may only need this behavior if the *entire* HTTP request came in over
early data, and that requiring this behavior if *any* part of it came in
via early data may be overkill.  That said, I'm not convinced that it's
easy to robustly implement an API for that in all TLS stacks, so going
with the stronger requirement may be safest.

>>> (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.
> That's very close to our initial model consisting in having 0, 1 and 2
> typically for "none, sent, received", that we found problematic when
> chaining multiple intermediaries because in case the 0-RTT was used
> again further down the path it was a bit confusing. My point was that
> it was important to distinguish between the fact that a client attemped
> to use early-data and the fact that a server received it this way.
>
> I think that during this brainstorming we shoud avoid to think about
> "cheap" models that often break against one example. If instead we
> temporarily consider the Early-Data header field as a list of states
> having each 2 values ("sent", "received"), and that each sender has
> to append "sent" to the list and each receiver has to append "received",
> we can end up with something like this on the server side in Kazuho's
> case where an intermediary uses early-data to the server after using
> it with the client for example:
>
>    Early-Data: sent, received, sent, received
>
> At least the server gets all the information about what happend on
> the path. Now the question is : what should the server do with such
> information, what is useful there and how could it be simplified.
>
> If we have the confirmation that TLS APIs provide the information that
> at least some data were received as early data before ClientFinished,
> then we can remove the "sent" list (that said, APIs evolve and if we
> make it mandatory to have that signal in order to map HTTP on top of
> TLS 1.3 0-RTT, it will exist).
>
> Early-Data then becomes a list of "received" fields and we'll note
> that a server is interested in seeing at least one entry, which comes
> back to the current proposal of "were some early-data received anywhere
> along the path before a ClientFinished, tagging the request as
> potentially unsafe ?", leaving the responsibility to the first such
> receiver on the path to tag the request before passing it.
>
> By the way there's something I actually like with the current proposed
> method of "tagging" a request as unsafe where it was first noticed : it
> doesn't require the ability anywhere to modify an existing header's
> contents at all, reducing the temptation for implementers to "untag"
> a request that was tagged by a previous intermediary. Using a counter
> requires such a change and we could expect some bugs where an intermediary
> retrying a connection using 1-RTT after having tried 0-RTT would decrement
> the header's content to indicate that finally it's not sending this way.
> And if it retries multiple times and is poorly implemented it could even
> remove some of the previous counts, which I don't really like :-/

Thanks for cluing me in on the history.  Your reasoning seems sound, and
I no longer think that the incrementing counter could provide real value
over the current proposal.

-Ben