Re: Comments on draft-ietf-httpbis-replay-01.txt

Hi Eric,

On Fri, Nov 17, 2017 at 10:02:17AM +0800, Eric Rescorla wrote:
> This document seems like it's in good shape and is mostly ready for WGLC.
> Some detailed comments below.

Thanks for your comments, here are some of mine below.

> S 3.
>    A server decides whether or not to offer a client the ability to send
>    early data on future connections when sending the TLS session ticket.
> 
> This reveals an ambiguity in the QUIC spec. See
> https://github.com/quicwg/base-drafts/issues/942

Wasn't this max_early_data server parameter initially designed to
advertise how many bytes of early data the server is able to store ?
We probably need to be careful regarding this, as some implementations
may experience difficulties if they rely on separate buffers. I believe
that openssl's client code uses this as a max for the number of bytes
to send.

>    A server can partially process requests that are incomplete.  Parsing
>    header fields - without acting on the values - and determining
>    request routing is likely to be safe from side-effects, but other
>    actions might not be.
> 
> This text seems like it might be sharper. If you receive a request that
> is partly in early data, but you don't process it until you have
> the whole request, this guarantees that it has not been replayed
> to you but not to others, if they start processing earlier. So maybe
> say:
> 
>    what matters is when servers starts acting upon the contents
>    of a request.  Any time any server instance might initiate
>    processing prior to completion of the handshake, all server instances
>    need to consider how a possible replay of early data could affect that
>    processing (see also Section 6.2).

I think it's indeed better this way. Probably that we can add that a
completed handshake confirms the validity of initially seen data, as
some implementers may wonder if they need to restart processing from
scratch once the handshake completes.

> S 4.
>    If the server rejects early data at the TLS layer, a client MUST
>    start sending again as though the connection was new.  For HTTP/2,
>    this means re-sending the connection preface.  Any requests sent in
>    early data MUST be sent again, unless the client decides to abandon
>    those requests.
> 
> You should mention here that this might need ALPN negotiation.

Then we should mention it before the HTTP/2 sentence so that the text
flows according to the operations flow.

> S 5.
>       The "Early-Data" header field is included in requests that are
>       received in early data.
> 
> Do you mean "partially received" here?

It's "at least partially received", or "at least one bit from this request
was determined based on contents received in early data". I remember my
coworker who implemented it in haproxy asked me a similar question, we
need to reformulate this one I think.

> S 5.2.
>    Clients (user-agents and intermediaries) that sent the request in
>    early data MUST automatically retry the request when receiving a 425
>    (Too Early) response status code.  Such retries MUST NOT be sent in
>    early data.
> 
>    Intermediaries that receive a 425 (Too Early) status code MAY
>    automatically retry requests after allowing the handshake to complete
>    unless the original request contained the "Early-Data" header field
>    when it was received.  Otherwise, an intermediary MUST forward the
>    425 (Too Early) status code.
> 
> I am having trouble reading this text. It seems to me that the first
> graf says that intermediaries MUST retry when I receive 425, and then
> the second graf says that it MUST instead forward 425 if the
> Early-Data header was not in the request.

You're right, I think we should simply remove the parenthesis in the
first paragraph and leave "clients".

Thanks!
Willy

Received on Friday, 17 November 2017 05:40:58 UTC