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


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.

> > (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 :-/

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

Yep, which shows the importance of the first hop making use of some
Early-Data here in this chain. If we called this header field "untrusted"
or "unsafe" it would be obvious that it's the first receiver's responsibility
to put such a stamp on such a request.


Received on Monday, 31 July 2017 03:43:52 UTC