Using Early Data in HTTP
draft-ietf-httpbis-replay-04
Yes
(Alexey Melnikov)
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 02 and is now closed.
Adam Roach Former IESG member
Yes
Yes
(2018-06-05 for -03)
Unknown
Thanks to everyone who worked on this document. I appreciate its concision and clarity. I have one comment that is either quite important or a misunderstanding on my part, followed by a couple of very minor editorial nits. --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- Presumably, the "Note to Readers" section immediately following the abstract is to be removed prior to publication? Please either remove it or add a note that the RFC editor should remove it. --------------------------------------------------------------------------- §4: > If the server rejects early data at the TLS layer, a client MUST > start sending again as though the connection was new. nit: s/was new/were new/
Alexey Melnikov Former IESG member
Yes
Yes
(for -02)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(2018-06-06 for -03)
Unknown
Just some minor (mostly editorial) comments: Substantive: §3, item 2: It seems odd to find "reject early data" in a list of mitigation strategies for servers that enable early data. Editorial and Nits: §3, latter part: There's a tendency to use language that gives anthropomorphic agency to inanimate objects or concepts. I find that a bit jarring. (e.g., "if resources do elect" and "server instances need to consider" §5.1: "An intermediary MUST use the "Early-Data" header field if it might have forwarded the request prior to handshake completion (see Section 6.2 for details)." - inconsistent tense. (after forwarding seems a bit late to add the header field.) §5.2: "425 (Too Early): Are there degrees of earliness? §6.1: " A gateway that forwards requests that were received in early data MUST only do so if it knows that the origin server that receives those requests understands" Consider "MUST NOT unless...". "MUST ONLY" can be ambiguous whether it means don't do it unless the condition occurs, you are only required to do it when the condition occurs, or you must do that and nothing else when the condition occurs.
Benjamin Kaduk Former IESG member
Yes
Yes
(2018-06-04 for -03)
Unknown
I spent a lot of time reviewing earlier versions of this document, so it should not be surprising that I am balloting "yes". That said, I do have a handful of comments. Section 1 Early data allows a client to send data to a server in the first round trip of a connection, without waiting for the TLS handshake to complete if the client has spoken to the same server recently nit: comma before "if the client" Section 3 For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server). In general, if processing a request does not have state-changing side effects, the consequences of replay are not significant. It seems that even the size of the reply is potentially a side effect, though it's unclear how significant of an effect (or side channel) it is. Intermediary servers do not have sufficient information to make this determination, so Section 5.2 describes a way for the origin to signal to them that a particular request isn't appropriate for early data. Intermediaries that accept early data MUST implement that mechanism. We may be sufficiently far from the antecedent that "this determination" needs disambiguating? Section 4 By their nature, clients have control over whether a given request is sent in early data - thereby giving the client control over risk of replay. Absent other information, clients MAY send requests with safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when it is available, and SHOULD NOT send unsafe methods (or methods whose safety is not known) in early data. Since this is already couched in "absent other information", we could probably get away with "MUST NOT" here. Automatic retry creates the potential for a replay attack. An attacker intercepts a connection that uses early data and copies the early data to another server instance. The second server instance accepts and processes the early data. The attacker then allows the original connection to complete. Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete. If the client then retries requests that were sent in early data, the request will be processed twice. Perhaps it's helpful to note that the second server instance will fail to complete the TLS handshake (but has still processed the HTTP data)?
Mirja Kühlewind Former IESG member
Yes
Yes
(2018-06-06 for -03)
Unknown
Some questions: 1) sec 5.1: "Multiple instances MUST be treated as equivalent to a single instance by a server." What happens if the multiple instances have different values? Does that generate an error? Or more generally, what if the value is not 1? 2) "The server cannot assume that a client is able to retry a request unless the request is received in early data or the "Early-Data" header field is set to "1". A server SHOULD NOT emit the 425 status code unless one of these conditions is met." Shouldn't actually both criteria be met? 3) Are there any additional risks/attacks possible with the use of the "Early-Data" header field or "Too Early" status code? I thought that should be covered in the security considerations as well...
Alissa Cooper Former IESG member
No Objection
No Objection
(for -03)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -03)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -03)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(2018-06-07 for -03)
Unknown
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4635 COMMENTS S 3. > basis. > > 5. The server can cause a client to retry a request and not use > early data by responding with the 425 (Too Early) status code > (Section 5.2), in cases where the risk of replay is judged too > great. I think the point you want to bring out here is that this allows you to bounce individual requests, as opposed to point #2. In fact, you might want to say "at the TLS layer" in point #2. S 3. > (Section 5.2), in cases where the risk of replay is judged too > great. > > For a given request, the level of tolerance to replay risk is > specific to the resource it operates upon (and therefore only known > to the origin server). In general, if processing a request does not This is partly true, but note that the client knows whether it would replay it. S 3. > > For a given request, the level of tolerance to replay risk is > specific to the resource it operates upon (and therefore only known > to the origin server). In general, if processing a request does not > have state-changing side effects, the consequences of replay are not > significant. This seems to contradict the claims in the TLS 1.3 security considerations about side channels. S 3. > A server can limit the amount of early data with the > "max_early_data_size" field of the "early_data" TLS extension. This > can be used to avoid committing an arbitrary amount of memory for > deferred requests. A server SHOULD ensure that when it accepts early > data, it can defer processing of requests until after the TLS > handshake completes. I don't understand this last line. You don't have to defer, so why should you ensure that? S 4. > By their nature, clients have control over whether a given request is > sent in early data - thereby giving the client control over risk of > replay. Absent other information, clients MAY send requests with > safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when > it is available, and SHOULD NOT send unsafe methods (or methods whose > safety is not known) in early data. Is that what browsers plan to do? S 4. > If the server rejects early data at the TLS layer, a client MUST > start sending again as though the connection was new. This could > entail using a different negotiated protocol [ALPN] than the one > optimistically used for the early data. Any requests sent in early > data MUST be sent again, unless the client decides to abandon those > requests. This MUST in connection with the "unless the client"... seems confusing. Perhaps "will need to be..." S 4. > were sent in early data, the request will be 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 > Section 8 of [TLS13]). To be clear, only the second part of this is in violation S 5.1. > An intermediary that forwards a request prior to the completion of > the TLS handshake with its client MUST send it with the "Early-Data" > header field set to "1" (i.e., it adds it if not present in the > request). An intermediary MUST use the "Early-Data" header field if > it might have forwarded the request prior to handshake completion > (see Section 6.2 for details). I don't actually see these details, so perhaps this can be rewritten more clearly? S 5.1. > A server cannot make a request that contains the Early-Data header > field safe for processing by waiting for the handshake to complete. > A request that is marked with Early-Data was sent in early data on a > previous hop. Requests that contain the Early-Data field and cannot > be safely processed MUST be rejected using the 425 (Too Early) status > code. I think in order for this to be true you need to prohibit clients sending with Early-Data=1
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -03)
Unknown
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2018-06-05 for -03)
Unknown
When I read the list of replay mitigation measures in Section 3, I found myself wondering how an implementer would choose among them. The text that follows the list is helpful, but MUCH later in the Security Considerations section, I find Disabling early data, delaying requests, or rejecting requests with the 425 (Too Early) status code are all equally good measures for mitigating replay attacks on requests that might be vulnerable to replay. which ISTM would also be helpful guidance. I'm confused about something in this text. 5. Extensions for Early Data in HTTP Because HTTP requests can span multiple "hops", it is necessary to explicitly communicate whether a request has been sent in early data on a previous connection. Do you mean "sent in early data on a previous hop", or something else? I could guess, but I'm guessing. This is a side question - I understand that you're using the absence of the Early-Data header field as "not early data", but wondered if there was anything about that choice, that would be good for people maintaining the protocol to know. 5.1. The Early-Data Header Field The "Early-Data" request header field indicates that the request has been conveyed in early data, and additionally indicates that a client understands the 425 (Too Early) status code. It has just one valid value: "1". Its syntax is defined by the following ABNF [ABNF]: Early-Data = "1" Would there ever be an HTTP version with "Early-Data: 2"? (That's just to give me a clue, not requesting any change to the text) I'm wondering why this text User agents that send a 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. has automatic retry as a MUST. I see the MUST NOT in the next sentence. Is the MUST also required for interoperation? I'm reading A gateway without at least one potential origin server that supports "Early-Data" header field expends significant effort for what can at best be a modest performance benefit from enabling early data. If no origin server supports early data, disabling early data entirely is more efficient. "can at best a modest performance benefit" as saying that if you don't have any origin servers that support "Early-Data", you still get a performance benefit by enabling early data. Am I misreading this? If this said A gateway without at least one potential origin server that supports "Early-Data" header field expends significant effort for what could at best have been a modest performance benefit from enabling early data. If no origin server supports early data, disabling early data entirely is more efficient. (If I understood the next one better, I might have balloted Discuss, but "let's talk even if I balloted No Objection") There are constraints at various places in the specification that require server instances to know things about other server instances. To pick one, which is the one that made me wonder, but there are more ... 6.4. Out of Order Delivery In protocols that deliver data out of order (such as QUIC [HQ]) early data can arrive after the handshake completes. A server MAY process requests received in early data after handshake completion if it can rely on other instances correctly handling replays of the same requests. Is it obvious how the server would know that? And could a new instance that doesn't correctly handle replays of the same requests come into the picture?
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -03)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -03)
Unknown