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

On 09/21/2017 09:33 PM, Willy Tarreau wrote:
>>> 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.
>

At risk of adding too many words, I submit:

"In some deployments the TLS server functionality is provided by a
cluster or pool of independent machines that share credentials and key
material for server authentication and session resumption, subject to
some form of load balancing.  In order to safely process early data
before the handshake completes, such deployments also need to share a
common algorithm for determining whether a given HTTP request is safe to
begin processing before the handshake completes.  A server MUST NOT act
on early data before the handshake completes if it belongs to such a
cluster or pool and there is not such an agreed algorithm for
determining request safety.  Similarly, a gateway MUST NOT process a
request received in early data absent knowledge that all downstream
gateways and/or server instances will use the same algorithm for
determining whether the request is safe to process as early data.  In
both the server-in-pool and gateway cases, if a request is received
containing the Early-Data header field, the server MUST respond with a
4NN (Too Early) status code without processing the request; if the
Early-Data header is not present but the request is received in early
data, the server MUST wait for the handshake to complete before
processing the request or respond with a 4NN (Too Early) status code
without processing the request."

-Ben