Re: Review of draft-thomson-http-replay-latest

Thanks for the feedback Victor.

On 4 August 2017 at 03:54, Victor Vasiliev <vasilvv@google.com> wrote:
> The profile does not define whether a single request can span from early
> to non-early data, or whether, say, a single HTTP/2 frame can cross that
> boundary (for TLS 1.3 over TCP).

That's a mistake.  It was in an early draft and got removed.  I opened
https://github.com/martinthomson/http-replay/pull/28 for this.

> In general, there are two world views possible here:
> * Being "early" is an inherent property of data transmitted over TLS,
>   with some data being inherently marked as "early" by virtue of being
>   transmitted using early data keys.
> * Being "early" is a temporal property of the data; the data is early
>   until the server receives a liveness proof from the client.
> (this is so far without taking into account relays)

This second model is actually what we arrived at, but likely failed to
articulate well.

However, I think that you need to at least recognize the first model
to be entirely safe.  As I noted in #28 above, even if the handshake
completes, it doesn't mean that the once-early data is entirely safe.
This goes back to the need for consistent handling.

> The semantics of the header is currently tied to the first approach, the
> one where being "early" is the property of the data itself.  This could
> be easily avoided by shifting the definition to the one based on desired
> security semantics instead of a particular mechanism: the header should
> be defined as "indication that the intermediary believes the request
> could potentially be a 0-RTT replay".  I would also rename it to
> something like Not-Replay-Safe.

In practice, this won't do anything other than change the name.
Keeping the focus on mechanics makes this somewhat more concrete, I
think.

> 4NN error code should specify that the server must not process the
> request if it actually receives, and in general should have same
> semantics as HTTP/2 REFUSED_STREAM (I expect the user agents to
> implement them at the same place).

Right.

> I believe that with semantics above it should be safe for intermediaries
> retry requests on 4NN.  This potentially saves the time it takes to
> process the request, from two full round-trip times between the client
> and the server to one full round-trip time plus largest of {RTT between
> client and intermediary, RTT between intermediary and server}.  This, of
> course, can be done only if the intermediary did not receive Early-Data
> header from upstream, which is why it's important for the clients to not
> send Early-Data header.

Opened https://github.com/martinthomson/http-replay/issues/29 - I'll
work on a proposal.

> ## Pull request 25
>
> So far, this has been a review of latest editor's copy of the draft.
> There is also https://github.com/martinthomson/http-replay/pull/25
>
> I believe that this pull request should not be adopted.

I have closed that PR based on this (and other) feedback.

> ## Minor points
>
> "replays are under the control of an attacker, and are therefore
> malicious" -- I am not sure "malicious" is the right word here; retries
> can be also attacker-induced.  The important distinction is that replays
> can be done in much greater quantity and without the client's knowledge.

https://github.com/martinthomson/http-replay/pull/30 - I think that
the point about greater quantity is largely addressed by the
mitigations that TLS now mandates.

Received on Friday, 4 August 2017 00:51:36 UTC