W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

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

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 7 Jun 2018 18:27:58 +0200
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Martin Thomson <martin.thomson@gmail.com>, httpbis-chairs@ietf.org, Eric Rescorla <ekr@rtfm.com>, Patrick McManus <mcmanus@ducksong.com>, The IESG <iesg@ietf.org>, draft-ietf-httpbis-replay@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20180607162758.GB20365@1wt.eu>
On Thu, Jun 07, 2018 at 11:21:28AM -0500, Benjamin Kaduk wrote:
> On Thu, Jun 07, 2018 at 11:05:03AM +0200, Willy Tarreau wrote:
> > 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
> > > 
> > > 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.
> 
> I agree that the SHOULD is not needed, but wonder if there is value
> in retaining some statement along the lines of "servers that choose
> to buffer have a knob available to control how big of a buffer they
> need to reserve".

While usually I wouldn't suggest such apparently trivial stuff, here
we're speaking about having such a buffer available at a very unexpected
moment or place in an implementation, and I think that placing such a
warning regarding the impacts of using early data in existing code, and
explaining how to adjust it could save a number of people from trying and
wasting their time if it's not designed at all to accept this.

It's not critical though, but I definitely think it's easier to find
in an HTTP-related spec than in the TLS one for most HTTP implementers.

Regards,
Willy
Received on Thursday, 7 June 2018 16:28:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC