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

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

I've a PR for you here:

On Thu, Jun 7, 2018 at 11:27 AM Willy Tarreau <> wrote:
> On Wed, Jun 06, 2018 at 12:23:31PM -0700, Ben Campbell wrote:
> > §3, item 2:  It seems odd to find "reject early data" in a list of mitigation
> > 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.

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.

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

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

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

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

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

Received on Friday, 8 June 2018 10:02:08 UTC