Re: Adam Roach's Yes on draft-ietf-httpbis-replay-03: (with COMMENT)

[Willy Tarreau <[e-mail]>]

Hello Adam,

first, thanks for your review.

On Tue, Jun 05, 2018 at 10:52:38PM -0700, Adam Roach wrote:
> ---------------------------------------------------------------------------
> 
> §5.2:
> 
> >  In all cases, an intermediary can forward a 425 (Too Early) status
> >  code.  Intermediaries MUST forward a 425 (Too Early) status code if
> >  the request that it received and forwarded contained an "Early-Data"
> >  header field.  Otherwise, an intermediary that receives a request in
> >  early data MAY automatically retry that request in response to a 425
> >  (Too Early) status code, but it MUST wait for the TLS handshake to
> >  complete on the connection where it received the request.
> 
> This seems correct but incomplete.
> 
> I believe that we also want to (MUST-level) require the forwarding of the 425
> in the case in which an intermediary receives a request from a client in early
> data (i.e., no "Early-Data" header field), forwards it towards the origin
> (with an "Early-Data" header field), and then receives a 425 response. I
> suspect the intention here was to cover that case in the "MUST" above, but
> it's not what the text actually says.

I'm not sure I get exactly the case you want to cover or what you would
like to adjust. The purpose of what is (possibly poorly) explained in the
original text is to ensure that the following cases are properly covered :

  - client sending a request using early data, intermediary forwarding it
    before waiting for handshake to complete, receiving 425 thus forwarding
    425 to the client to ask it to retransmit without using early data ;

  - client sending a request using early data, intermediary forwarding it
    before waiting for handshake to complete, receiving 425 but having the
    whole request buffered, so it can wait for the handshake to complete
    and then retry without bothering the client since after the handshake
    completes the request is safe.

  - client sending a request using early data, the first intermediary
    forwards it before waiting for handshake to complete, adding an
    Early-Data header field, then a second intermediary receives it,
    passes it to the server which responds 425. In this case the second
    intermediary has no way to wait for a handshake to complete, it must
    return 425 to the first intermediary (its own client). The first
    intermediary now is in either of the two cases above, it may either
    send 425 to the client or retry it by itself if it is able to wait
    for the handshake to complete.

Please let us know if there's still something unclear in this explanation
and/or what part of the original text needs to be adjusted to more clearly
reflect these points.

Thank you!
Willy