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

This document seems like it's in good shape and is mostly ready for WGLC.
Some detailed comments below.

-Ekr


   The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
   document.  It's not shouting; when they are capitalized, they have
   the special meaning defined in [RFC2119].

You should just cite RFC 8174.


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


   A request might be sent partially in early data with the remainder of
   the request being sent after the handshake completes.  This does not
   necessarily affect handling of that request; what matters is when the
   server starts acting upon the contents of a request.  Any time a
   server might initiate processing prior to completion of the handshake
   it needs to consider how a possible replay of early data could affect
   that processing (see also Section 6.2).

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


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.


This automatic retry exposes the request to a potential replay
   attack.  An attacker sends early data to one server instance that
   accepts and processes the early data, but allows that connection to
   proceed no further.  The attacker then forwards the same messages
   from the client to another server instance that will reject early
   data.  The client then retries the request, resulting in the request
   being processed twice.  Replays are also possible if there are
   multiple server instances that will accept early data, or if the same
   server accepts early data multiple times (though this would be in
   violation of requirements in TLS).

You should cite the specific section in TLS (S 8).


S 5.
      The "Early-Data" header field is included in requests that are
      received in early data.

Do you mean "partially received" here?


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.