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

From: Victor Vasiliev <[email-masked]>
Date: Fri, 1 Dec 2017 13:50:16 -0500

On Thu, Nov 30, 2017 at 7:19 PM, Martin Thomson <[email-masked]>
wrote:

> Hi Victor,
>
> I think that most of your comments were addressed in response to other
> reviews, but there is one thing no one else picked up on:
>
> On Thu, Nov 30, 2017 at 3:24 AM, Victor Vasiliev <[email-masked]>
> wrote:
> > "Implementations MUST either ensure that any early data that is delivered
> > late
> > is either discarded or consistently identified and processed." -- I am
> not
> > quite sure what exactly this means.  Is that (re)statement of the
> > requirement
> > that the early data status is not changed in the middle of processing?
>
> Late delivery of early data could lead to a server (or intermediary
> acting as one) processing that data in a fashion that is inconsistent
> with other server instances.  While it's true that the data wasn't
> replayed toward *this* server instance, that doesn't mean that it
> wasn't replayed toward another instance.  It's important to treat that
> data properly.
>

I am not sure I understand the attack scenario you have in mind here.  If
all instances
of the server believe the request is safe, all of them can process it at
any point.  If all
instances of the server believe the request is not safe, the one which
receives the
non-replay version will process it as soon as it finishes the handshake,
regardless of
how it was received, and all instances to which it's being replayed would
reply with 425
to it, or buffer (since the handshake will be never confirmed).

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 1 Dec 2017 20:47:58 +0100

> to it, or buffer (since the handshake will be never confirmed).

That's exactly why it's requested that all servers are configured
consistently. As you demonstrated, as long as "all of them" is granted
regardless of the decision, the processing is safe. What is important
is that you can't end up in a situation whose starts with "some servers".

Willy

---

From: Alessandro Ghedini <[email-masked]>
Date: Fri, 1 Dec 2017 21:32:07 +0000

On Fri, Nov 24, 2017 at 02:43:38AM +0000, Patrick McManus wrote:
> Hi All - When we met in Singapore we discussed a couple final details of
> the Early Data / Replay draft and indicated we would start WGLC after a
> final(?) update. The authors have made that update and we're ready for the
> LC now.
> 
> Please have a look at:
> https://tools.ietf.org/html/draft-ietf-httpbis-replay-02
> 
> Raise any issues either on the mailing list or in the issues list.
> Statements of support, implementation, or intent to implement to the list
> would also be helpful.

I very much support this document and we (Cloudflare) are in the process of
implementing and deploying it.

Cheers

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Dec 2017 11:57:58 +1100

On Mon, Dec 4, 2017 at 11:53 AM, Victor Vasiliev <[email-masked]> wrote:
> On Fri, Dec 1, 2017 at 2:47 PM, Willy Tarreau <[email-masked]> wrote:
>>
> That's what I thought.  But Martin's email makes it sound like there is a
> reason to discard early data when it's received after handshake completion,
> instead of treating it as replay-secure.

If there is a chance that you would have accepted (and processed)
those packets prior to handshake completion, you have an exposure.
This is just a another case of the consistency requirement.

---

From: Victor Vasiliev <[email-masked]>
Date: Sun, 3 Dec 2017 19:53:56 -0500

---

From: Victor Vasiliev <[email-masked]>
Date: Sun, 3 Dec 2017 20:07:32 -0500

Are we talking about the "scenarios in the middle" when a request is
processed
differently on 0-RTT and 1-RTT, but the 0-RTT processing is actually
meaningful
(not 425 or buffering)?  Because if you process request same regardless of
whether it's 0-RTT or 1-RTT, you're consistent.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Dec 2017 12:09:14 +1100

> whether it's 0-RTT or 1-RTT, you're consistent.

Yeah, it's the cases where you might do meaningful processing on 0-RTT
and that processing might have side effects.

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 5 Dec 2017 09:58:25 -0500

I've been trying to think about the cases when that would be useful, but
I'm drawing a blank here.  Even if those exist, I am not sure how one
would analyze those.  I for some reason thought that those cases were
disallowed as a consequence of consistency requirements.

Do you have a good use case in mind for processing 0-RTT in manner other
than "identical to 1-RTT, buffer or 425"?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Dec 2017 16:27:45 +1100

Hi Victor,

Your question actually suggests an answer:

> than "identical to 1-RTT, buffer or 425"?

Not that I have a use case, but that we would be presumptuous to
assume that there is something else.  I would hate to see Vary:
Early-Data, but it's possible, especially given the alignment of
incentives.

Imagine a web page that includes some potentially-replay-vulnerable
bits inlined.  A 0-RTT response might include a subset of what might
be contained in a 1-RTT response, with dangerous parts elided and
later filled in.

---

From: David Benjamin <[email-masked]>
Date: Thu, 07 Dec 2017 21:10:24 +0000

(Sending from the right address this time.)

On Thu, Dec 7, 2017 at 4:08 PM David Benjamin <[email-masked]> wrote:

> On Thu, Dec 7, 2017 at 12:37 AM Martin Thomson <[email-masked]>
> wrote:
>
>> Hi Victor,
>>
> 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.
>
> In that case, perhaps server A received out-of-order early data and treats
> those as replay-safe and sends the inlined version. This has side effects,
> but we've had handshake confirmation at this point, so it's okay per the
> second paragraph of section two. Then perhaps those packets are replayed to
> server B such that they are received before the handshake completes. Is
> that your concern? That server would then considers the request early data
> and instead sends out-of-line version, which does not have side effects. In
> total, the side effects still only happened only once.
>
> In fact, it seems acting on the out-of-order early data packets after the
> handshake is exactly the same thing as the deferred processing technique,
> which section three says is okay.
>
> David
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Dec 2017 10:15:47 +1100

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

---

From: David Benjamin <[email-masked]>
Date: Fri, 08 Dec 2017 00:28:17 +0000

> (reject, complete, retry), then we're good.

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Dec 2017 11:56:43 +1100

On Fri, Dec 8, 2017 at 11:28 AM, David Benjamin <[email-masked]> wrote:
> 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.

That's a good point and one we don't capture properly.  The point
about consistency needs to be on classification, not reaction.

I've opened a PR that tries to capture this, though I omit any
dependency between steps.

https://github.com/httpwg/http-extensions/pull/446

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 8 Dec 2017 08:03:25 -0600

> about consistency needs to be on classification, not reaction.

Yes, the consistency is of classification.  We have at least at times
had some text mentioning that it's always okay to return 425 due to
local conditions even if the response could safely be handled as an
early request, but I don't remember if that got lost in a reshuffling.

-Ben