Skip to main content

Using Early Data in HTTP
RFC 8470

Revision differences

Document history

Date Rev. By Action
2018-09-21
04 (System)
Received changes through RFC Editor sync (created alias RFC 8470, changed abstract to 'Using TLS early data creates an exposure to the possibility of …
Received changes through RFC Editor sync (created alias RFC 8470, changed abstract to 'Using TLS early data creates an exposure to the possibility of a replay attack.  This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data.  Techniques are described that use these mechanisms to mitigate the risk of replay.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-09-21, changed IESG state to RFC Published)
2018-09-21
04 (System) RFC published
2018-09-20
04 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-09-14
04 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-08-24
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-07-09
04 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on Authors
2018-07-02
04 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-06-29
04 (System) RFC Editor state changed to EDIT
2018-06-29
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-06-29
04 (System) Announcement was received by RFC Editor
2018-06-29
04 (System) IANA Action state changed to In Progress
2018-06-29
04 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-06-29
04 Amy Vezza IESG has approved the document
2018-06-29
04 Amy Vezza Closed "Approve" ballot
2018-06-29
04 Amy Vezza Ballot approval text was generated
2018-06-29
04 Alexey Melnikov IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2018-06-27
04 Martin Thomson New version available: draft-ietf-httpbis-replay-04.txt
2018-06-27
04 (System) New version approved
2018-06-27
04 (System) Request for posting confirmation emailed to previous authors: Martin Thomson , Willy Tarreau , Mark Nottingham
2018-06-27
04 Martin Thomson Uploaded new revision
2018-06-27
04 Martin Thomson Uploaded new revision
2018-06-12
03 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2018-06-07
03 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2018-06-07
03 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-06-07
03 Eric Rescorla
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4635



COMMENTS
S 3.
>          basis.

>      5.  The server …
[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
2018-06-07
03 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-06-07
03 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-06-06
03 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-06-06
03 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-06-06
03 Ben Campbell
[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 …
[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.
2018-06-06
03 Ben Campbell [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell
2018-06-06
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-06-06
03 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-06-06
03 Mirja Kühlewind
[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 …
[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...
2018-06-06
03 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-06-06
03 Mirja Kühlewind
[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 …
[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...
2018-06-06
03 Mirja Kühlewind [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind
2018-06-05
03 Adam Roach
[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 …
[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/
2018-06-05
03 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2018-06-05
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-06-05
03 Spencer Dawkins
[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. …
[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?
2018-06-05
03 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-06-04
03 Benjamin Kaduk
[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".  …
[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)?
2018-06-04
03 Benjamin Kaduk [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk
2018-06-02
03 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-05-30
03 Erik Kline Request for Telechat review by GENART Completed: Ready. Reviewer: Erik Kline. Sent review to list.
2018-05-17
03 Jean Mahoney Request for Telechat review by GENART is assigned to Erik Kline
2018-05-17
03 Jean Mahoney Request for Telechat review by GENART is assigned to Erik Kline
2018-05-10
03 Alexey Melnikov Placed on agenda for telechat - 2018-06-07
2018-05-03
03 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-05-03
03 Martin Thomson New version available: draft-ietf-httpbis-replay-03.txt
2018-05-03
03 (System) New version approved
2018-05-03
03 (System) Request for posting confirmation emailed to previous authors: Martin Thomson , Willy Tarreau , Mark Nottingham
2018-05-03
03 Martin Thomson Uploaded new revision
2018-05-03
03 Martin Thomson Uploaded new revision
2018-05-03
02 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Magnus Nystrom.
2018-05-01
02 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-04-30
02 Alexey Melnikov Ballot has been issued
2018-04-30
02 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2018-04-30
02 Alexey Melnikov Created "Approve" ballot
2018-04-30
02 Alexey Melnikov Ballot writeup was changed
2018-04-30
02 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup
2018-04-23
02 Erik Kline Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Erik Kline. Sent review to list.
2018-04-23
02 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-04-20
02 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-04-20
02 Sabrina Tanamal
(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 …
(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
2018-04-19
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2018-04-19
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2018-04-12
02 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2018-04-12
02 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2018-04-10
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2018-04-10
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2018-04-09
02 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-04-09
02 Amy Vezza
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 …
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.




2018-04-09
02 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-04-09
02 Amy Vezza Last call announcement was changed
2018-04-08
02 Alexey Melnikov Last call was requested
2018-04-08
02 Alexey Melnikov Last call announcement was generated
2018-04-08
02 Alexey Melnikov Ballot approval text was generated
2018-04-08
02 Alexey Melnikov Ballot writeup was generated
2018-04-08
02 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2018-04-08
02 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2018-03-27
02 Patrick McManus
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 …
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.
 
2018-03-27
02 Patrick McManus Responsible AD changed to Alexey Melnikov
2018-03-27
02 Patrick McManus IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2018-03-27
02 Patrick McManus IESG state changed to Publication Requested
2018-03-27
02 Patrick McManus IESG process started in state Publication Requested
2018-03-27
02 Patrick McManus Changed document writeup
2018-03-27
02 Patrick McManus Changed consensus to Yes from Unknown
2018-03-27
02 Patrick McManus Intended Status changed to Proposed Standard from None
2017-12-13
02 Mark Nottingham Notification list changed to Patrick McManus <mcmanus@ducksong.com>
2017-12-13
02 Mark Nottingham Document shepherd changed to Patrick McManus
2017-11-23
02 Patrick McManus IETF WG state changed to In WG Last Call from WG Document
2017-11-23
02 Martin Thomson New version available: draft-ietf-httpbis-replay-02.txt
2017-11-23
02 (System) New version approved
2017-11-23
02 (System) Request for posting confirmation emailed to previous authors: Martin Thomson , Willy Tarreau , Mark Nottingham
2017-11-23
02 Martin Thomson Uploaded new revision
2017-11-15
01 Patrick McManus Added to session: IETF-100: httpbis  Fri-0930
2017-10-19
01 Martin Thomson New version available: draft-ietf-httpbis-replay-01.txt
2017-10-19
01 (System) New version approved
2017-10-19
01 (System) Request for posting confirmation emailed to previous authors: Martin Thomson , Willy Tarreau , Mark Nottingham
2017-10-19
01 Martin Thomson Uploaded new revision
2017-09-06
00 Patrick McManus This document now replaces draft-thomson-http-replay instead of None
2017-09-06
00 Martin Thomson New version available: draft-ietf-httpbis-replay-00.txt
2017-09-06
00 (System) WG -00 approved
2017-09-05
00 Martin Thomson Set submitter to "Martin Thomson ", replaces to draft-thomson-http-replay and sent approval email to group chairs: httpbis-chairs@ietf.org
2017-09-05
00 Martin Thomson Uploaded new revision