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

These are all good comments, thanks.  These are all actionable, so I
should have a PR (or PRs) to review soon.  Just not this week :)

On Fri, Nov 17, 2017 at 10:02 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 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.
>
>
>
>
>

Received on Friday, 17 November 2017 02:20:10 UTC