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

On Mon, Aug 7, 2017 at 5:08 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:

> On 08/06/2017 06:27 PM, Martin Thomson wrote:
>
> On 5 August 2017 at 05:58, Victor Vasiliev <vasilvv@google.com> <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.
>

To make sure I'm understanding you correctly, the scenario here is a server
is sufficiently under load that it would like to request a round-trip from
the peer before responding to GET /expensive_thing?

If the server is really overloaded, it can send HTTP 503. But I'm guessing
503 triggers a sharper client back-off than you like in this
scenario. Perhaps you're only sort-of-overloaded and retrying at 1-RTT is
fine? As you say, a sort-of-overloaded server could reject 0-RTT at the TLS
level instead. Though perhaps you have GET /cheap_thing that you are still
willing to respond to.

In that case, using one of the second two options seems fine to me. Perhaps
the consistency rule needs to be a bit more nuanced: It is always okay to
take an unsafe request and make it safe (either by waiting or 4xx) before
responding. But if you wish for certain kinds of requests to only be
handled safely, you had better consistently do this! If you're just trying
to deal with load, doing either is fine.

I don't think this would invalidate any of the rest of the reasoning.


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