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.
Received on Monday, 7 August 2017 23:05:56 UTC