Using Early Data in HTTP
draft-ietf-httpbis-replay-04

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
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...

[Ballot comment]
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 risk/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...

[Ballot comment]
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/

[Ballot comment]
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?

[Ballot comment]
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)?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-httpbis-replay-02. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single, new Message Header will be registered as follows:

Header Field Name: Early-Data
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the Hypertext Transfer Protocol (HTTP) Status Code Registry located at:

https://www.iana.org/assignments/http-status-codes/

a single, new status code is to be registered as follows:

Value: 425
Description: Too Early
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-04-23):

From: The IESG
To: IETF-Announce
CC: httpbis-chairs@ietf.org, mcmanus@ducksong.com, ietf-http-wg@w3.org, draft-ietf-httpbis-replay@ietf.org, alexey.melnikov@isode.com, Patrick McManus
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using Early Data in HTTP) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document: - 'Using Early Data in HTTP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-04-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document explains the risks of using early data for HTTP and
  describes techniques for reducing them.  In particular, it defines a
  mechanism that enables clients to communicate with servers about
  early data, to assure correct operation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/ballot/


No IPR declarations have been submitted directly on this I-D.

Technical Summary

This document defines requirements for the sending and handling of
early data at the HTTP layer. Early data is data associated with the
0-RTT phases of TLS 1.3 and QUIC and is subject to being replayed. The
document creates mechanisms for Clients, Servers, and Intermediaries
to communicate the status of early data and minimize the risk of
replay. It is applicable to all versions of HTTP.

Working Group Summary

Development of this document mostly focused on the relationship of
intermediaries with early data on both the client and server side of
their connection. Issues with partly recevied early data also
underwent considerable revision but without significant controversy.

Document Quality

Participation in the document's review and development was very
broad. The three authors come from a client, a CDN, and an
intermediary background. There was a high level of discussion
throughout the process and the Working Group Last Call received review
comments from 12 different individuals indicating thorough review.

There was strong consensus in the working group for this document with
many also expressing an eagerness to have it deployed in the same time
frame as TLS 1.3 deployment.

There are known implementations in a browser, server, and intermediary
and statements of intent to implement from several other parties.

Personnel

Patrick McManus is the document shepherd; Alexey Melnikov is the
responsible Area Director.