Re: Working Group Last Call for Using Early Data in HTTP

On Fri, Dec 01, 2017 at 01:50:16PM -0500, Victor Vasiliev wrote:
> 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).

That's exactly why it's requested that all servers are configured
consistently. As you demonstrated, as long as "all of them" is granted
regardless of the decision, the processing is safe. What is important
is that you can't end up in a situation whose starts with "some servers".

Willy

Received on Friday, 1 December 2017 19:48:29 UTC