Subject: Ben Campbell's Yes on draft-ietf-httpbis-replay-03: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 06 Jun 2018 12:23:31 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-httpbis-replay-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just some minor (mostly editorial) comments:

Substantive:

§3, item 2:  It seems odd to find "reject early data" in a list of mitigation
strategies for servers that enable early data.

Editorial and Nits:

§3, latter part: There's a tendency to use language that gives anthropomorphic
agency to inanimate objects or concepts. I find that a bit jarring. (e.g., "if
resources do elect" and "server instances need to consider"

§5.1: "An intermediary MUST use the "Early-Data" header field if it might have
forwarded the request prior to handshake completion (see Section 6.2 for
details)." - inconsistent tense. (after forwarding seems a bit late to add the
header field.)

§5.2: "425 (Too Early): Are there degrees of earliness?

§6.1: " A gateway that forwards requests that were received in early data
   MUST only do so if it knows that the origin server that receives
   those requests understands"
Consider "MUST NOT unless...". "MUST ONLY" can be ambiguous whether it means
don't do it unless the condition occurs, you are only required to do it when
the condition occurs, or you must do that and nothing else when the condition
occurs.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 7 Jun 2018 11:26:53 +0200

Hi Ben,

> strategies for servers that enable early data.

It's been clarified in the PR Martin added after your and Eric's review,
it now says "at the TLS layer". Indeed, technically a server could decide
when finding these early data whether it wants to accept or reject them
when receiving them. It may just be a matter of implementation.

> details)." - inconsistent tense. (after forwarding seems a bit late to add the

I'll leave this to native english speakers who will know better than me.

> §5.2: "425 (Too Early): Are there degrees of earliness?

We've had some bikeshedding discussions on this one. I also proposed clearer
(to me) alternatives which were longer such as "Early Data Not Acceptable",
and in the end we really don't care since for a few decades, humans have
stopped reading reasons. We've thought about other ones like "Unsafe" but
it doesn't say why it's unsafe and will cause confusion if we later want
to add other "unsafe" reasons. So let's keep the short one, especially to
gracefully handle situations where we could expect that batches of pipelined
requests would get rejected at once.

> the condition occurs, or you must do that and nothing else when the condition

I definitely agree with this one, it would indeed be clearer this way. I
suggest this :

    A gateway MUST NOT forward requests that were received in early data
    unless it knows that the origin server it will forward to understands ...

Thanks,
Willy

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Jun 2018 09:07:56 -0500

> On Jun 7, 2018, at 4:26 AM, Willy Tarreau <[email-masked]> wrote:
> 

Apologies, I meant to put a “ :-)” on this comment :-)

Otherwise, your responses all look good to me.

Ben.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Jun 2018 12:01:35 +0200

Thanks Ben (and Willy for doing the heavy lifting on this).

I've a PR for you here:

> when receiving them. It may just be a matter of implementation.

This is there primarily for completeness, but also because accepting
0-RTT as a whole means that you need to be willing to apply the other
potentially costly mitigation techniques.

> > resources do elect" and "server instances need to consider"

I tweaked those two, but these are a little hard to find with a text
search.  I probably missed others.

> I'll leave this to native english speakers who will know better than me.

I think that this is correct, but it misses a few little clues.  When
the intermediary forwards a request, if it (or another instance) might
have forwarded the request prior to handshake under different
circumstances.  Therefore:

An intermediary MUST use the `Early-Data` header field if it - or
another instance (see Section 6.2) - could have forwarded the request
prior to handshake completion if circumstances were different.

That will conflict with other changes I made for other ADs, but I
think that this is better again, so I'll try to remember to have this
one win when resolving the merge conflict.

> requests would get rejected at once.

:)  I proposed "Too Soon", but that wasn't as good for other reasons.