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

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