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?



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

Received on Monday, 7 August 2017 23:05:56 UTC