Re: Eric Rescorla's No Objection on draft-ietf-httpbis-replay-03: (with COMMENT)

On Thu, Jun 07, 2018 at 10:45:36AM +0200, Martin Thomson wrote:
> Thanks for reviewing ekr,
> 
> PR here: https://github.com/httpwg/http-extensions/pull/647
> 
> For my co-authors (and the WG, for those who are interested), this
> removes a toothless MUST and SHOULD in two places.  I'd appreciate a
> second pair of eyes on those changes.

I really like the better wording in your new version. It's clearer in
my opinion about the intents and goals.

> On Thu, Jun 7, 2018 at 9:49 AM Eric Rescorla <ekr@rtfm.com> wrote:
> > S 3.
> > >      A server can limit the amount of early data with the
> > >      "max_early_data_size" field of the "early_data" TLS extension.  This
> > >      can be used to avoid committing an arbitrary amount of memory for
> > >      deferred requests.  A server SHOULD ensure that when it accepts early
> > >      data, it can defer processing of requests until after the TLS
> > >      handshake completes.
> >
> > I don't understand this last line. You don't have to defer, so why
> > should you ensure that?
> 
> Mark, Willy, I'm inclined to cull this paragraph.  It's a hang-up from
> the time we thought that deferring was our best defense, I think.
> I've included that change in the PR.

I agree. Some might decide that whatever they process is safe for early
data and that they don't want to defer.

> > S 5.1.
> > >      A server cannot make a request that contains the Early-Data header
> > >      field safe for processing by waiting for the handshake to complete.
> > >      A request that is marked with Early-Data was sent in early data on a
> > >      previous hop.  Requests that contain the Early-Data field and cannot
> > >      be safely processed MUST be rejected using the 425 (Too Early) status
> > >      code.
> >
> > I think in order for this to be true you need to prohibit clients
> > sending with Early-Data=1
> 
> Yes, the middle sentence here is true only if the client doesn't
> decide to include the header field, but I'm thinking that it doesn't
> matter, and there is no real value in a strict prohibition on use of
> the header field.

In fact if the client sends the Early-Data=1, it will prevent the server
from waiting for the handshake and will force it to either process the
request or respond 425, just as if an intermediary had added this
Early-Data=1 and used 0-RTT again. Though I cannot find any beneficial
use case for this, we cannot rule out that some people see some value
in doing this.

Cheers,
Willy

Received on Thursday, 7 June 2018 09:05:51 UTC