Re: Working Group Last Call for Using Early Data in HTTP

On Thu, Dec 7, 2017 at 6:15 PM Martin Thomson <martin.thomson@gmail.com>
wrote:

> On Fri, Dec 8, 2017 at 8:10 AM, David Benjamin <davidben@chromium.org>
> wrote:
> > I don't follow how this scenario requires dropping out-of-order early
> > data. Perhaps you could write it down in more detail? Let's consider your
> > inline vs. out-of-line processing case.
>
> Hmm, I'll be honest, I hadn't done that exercise.  I was applying the
> "be consistent" rule, perhaps too slavishly.
>
> If packets are delayed toward A and replayed toward B, then you get
> different reactions from A and B.
>
> A processes the data because the handshake completed.
>
> B might delay the data - that's consistent.
>
> But B might respond with 425.  That's not obviously consistent.
> Intuitively, there doesn't seem to be any way to exploit it though.
>
> For me to be comfortable with this, we'd need to find a logical
> equivalence for 425 and delay.  I think that this equivalence can is:
>
> request is delivered early, request is delayed, handshake completes,
> request is processed
> request is delivered early, request is rejected, handshake completes,
> request is retried, request is processed
>
> If you consider the tuple of (delay, complete) as equivalent to
> (reject, complete, retry), then we're good.
>
> Does this make sense?
>

Makes sense. I think those should be pretty clearly equivalent, supposing
we believe they each are reasonable replay protections to begin with.

I actually think "consistency" is a bit of a misleading word, since you
only want it in one direction. Suppose you have a server which always
processes request over early data and another server which sends 425 or
maybe even doesn't enable 0-RTT at all. If it doesn't have any side effects
and you are, globally, okay processing it replayably, this is perfectly
fine. The second server is being overly pessimistic, but perhaps it has
other reasons for it. (Maybe DoS mitigation, maybe it can't resume this
particular PSK, maybe the 0-RTT config push hasn't gotten here yet, etc.)

Rather you can think about boolean OR. An individual server may or may not
perform some action without replay protection. A fleet of servers will
perform that same action without replay protection if *any* of the
individual servers will.

Thus, If you are okay performing that action without replay protection,
then you're cool with any arrangement. If you are not okay performing that
action without replay protection, then *none* of your servers should do so.
This can be achieved, on a per-server basis in several ways:

1. Don't turn on 0-RTT.
2. If (1) is too much because you want 0-RTT in other cases, delay
processing.
3. If (2) is too much because you don't like buffering, send a 425.

If you do one of those at each server, then you're happy.

David