On Thu, Nov 30, 2017 at 7:19 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > Hi Victor, > > I think that most of your comments were addressed in response to other > reviews, but there is one thing no one else picked up on: > > On Thu, Nov 30, 2017 at 3:24 AM, Victor Vasiliev <vasilvv@google.com> > wrote: > > "Implementations MUST either ensure that any early data that is delivered > > late > > is either discarded or consistently identified and processed." -- I am > not > > quite sure what exactly this means. Is that (re)statement of the > > requirement > > that the early data status is not changed in the middle of processing? > > Late delivery of early data could lead to a server (or intermediary > acting as one) processing that data in a fashion that is inconsistent > with other server instances. While it's true that the data wasn't > replayed toward *this* server instance, that doesn't mean that it > wasn't replayed toward another instance. It's important to treat that > data properly. > I am not sure I understand the attack scenario you have in mind here. If all instances of the server believe the request is safe, all of them can process it at any point. If all instances of the server believe the request is not safe, the one which receives the non-replay version will process it as soon as it finishes the handshake, regardless of how it was received, and all instances to which it's being replayed would reply with 425 to it, or buffer (since the handshake will be never confirmed).
Received on Friday, 1 December 2017 18:50:40 UTC