- 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>
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