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

On 08/07/2017 05:07 PM, David Benjamin wrote:
>
> 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?
>
Right.
-Ben
> 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.