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

On 08/06/2017 06:27 PM, Martin Thomson wrote:
> On 5 August 2017 at 05:58, Victor Vasiliev <vasilvv@google.com> wrote:
>> I assume this means we no longer need to be able to find the early data
>> boundary on the wire?
> Strange how these things progress...  I think that I'd like to hear
> what Ben thinks.  I can't think of a reason for this right now.
>
> (Clarity about the status of things is still probably desirable, but
> it seems that we don't have a concrete requirement that would make it
> mandatory.)
>

I think I've lost track of some of the reasoning in the previous
messages, so I had to try to re-derive some of it.

If I'm reading correctly, it's now being claimed that the important
property to retain is that the answer to the question "is this request
safe to respond to before the client is 'authenticated'?" must be
consistent across all nodes.  This is in the context of the previous
analysis which considered three possible options for a given 0-RTT request:

- Handle immediately
- Wait for ClientFinished (only available when Early-Data header is absent)
- Reject immediately

with the claim that reject and delay are in some sense equivalent, in
terms of the safety of the request.  So, combining the two statements we
would find that, for a given (HTTP-level?) request, all nodes must
either handle it and reply immediately, or take the other option.  (The
"other option" being, "pick one of 'reject immediately' and 'wait for
ClientFinished' (if applicable)".)

An interesting follow-up question is what the desired/permitted behavior
is when a node is under attack.  Luckily, the TLS 1.3 spec has forbidden
the use of just the timestamp check that would allow trivial replay
floods of captured packets, but an attacker could still be generating
new repeated 0-RTT requests of their own.  A node under attack clearly
has the option of rejecting 0-RTT entirely at the TLS layer, but do we
want it to also be able to shunt off "expensive" HTTP requests at the
HTTP layer?  If so, that seems in contradiction to the above requirements.

For the sake of argument, I'll proceed on the assumption that we want to
preserve this HTTP-level invariant and make TLS-layer 0-RTT reject the
only way to shed load while under attack.

Anyway, if we take as assumptions that all nodes consistently classify
requests as 0-RTT-safe/unsafe, and the further (natural) restriction
that the reply contents do not differ when handled as 0-RTT or handled
as 1-RTT, then there does not seem to be a reason to need the early data
boundary on the wire (as opposed to just the boolean "is the handshake
done?") -- safe requests always get a reply, and it's the same reply no
matter what.  Unsafe requests can get rejected or processed depending on
the handshake-done boolean, and nothing needs the "was any of this
request early data?" information.

I've also tried to think about what an attacker can do with delaying
traffic and/or replaying 0-RTT.  There doesn't seem to be much that the
attacker can do that's qualitatively different from observing the
ClientHello+0-RTT and replaying it at a different node, though.  So, I
think I agree with you (Martin + Victor), and the early data boundary on
the wire is probably not needed.

I'm sure we'll see problems with servers (and clients, I suppose) making
the wrong decision about requests being safe or not, but there's only so
much we can do about that in the spec.

-Ben