Re: Questions and comments about draft-ietf-httpbis-replay-00

Hi,

On Thu, Sep 21, 2017 at 02:26:43PM -0500, Benjamin Kaduk wrote:
> > Section 6.1: "A gateway that isn't certain about server support SHOULD
> > either delay forwarding the request until the TLS handshake
> > completes..." Obviously this is talking about the TLS handshake
> > between the client and the gateway, but it might be worth adding a
> > "with the client" after "handshake" just to make it blazingly obvious.
> 
> Sure.

In fact I'm a bit at fault on some of these points because I wanted to
add a diagram showing the different steps that could be referenced in
the text, but failed to find time to do it :-(

> > Section 6.2: Does there need to be normative language enforcing this
> > consistency constraint? If so, that opens a can of worms when servers
> > might have different behavior over time and no shared state.
> 
> Sigh ... there probably does need to be normative language, yes.
> And yes, that's a can of worms.

In fact I think we could add this as a prerequisite for accepting unvalidated
early data. Something more or less like this (but with a better wording) :

  A server MUST NOT use early data before the handshake completes if it is
  part of a cluster in which other members may possibly apply a different
  treatment to the same request. A gateway MUST NOT process a request
  received using early data if it is uncertain that all downstream server
  instances will apply the same treatment to the request, or if it is
  uncertain that other gateways exist with a possibly different behaviour.
  In both situations, if the receiving host sees the TLS connection, it MUST
  wait for the handshake to complete before processing the request. If it
  receives a request containing the Early-Data header field, it MUST respond
  with a 4NN (Too Early) status code without processing the request.

Willy

Received on Friday, 22 September 2017 02:33:34 UTC