Skip to main content

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