- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 17 Nov 2017 10:19:01 +0800
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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