I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes risk of using "early" (from a TLS 1.3 perspective) data for HTTP and defines a mechanism for clients to communicate with servers about such "early" data usage. a) For the Early-data field processing, the memo states: "The "Early-Data" header field is not intended for use by user agents (that is, the original initiator of a request). ... A user agent that sends a request in early data does not need to include the "Early-Data" header field " - would it make sense to either forbid ("MUST NOT send the "Early-Data" header field) or at least recommend against it ("SHOULD NOT send the Early-Data field")? b) I am probably missing something here: "A server cannot make a request that contains the Early-Data header field safe for processing by waiting for the handshake to complete" - if the origin server always wait for successful TLS handshake completion, why would it not be safe to process the early data at that point? Nits: - Section 2, first sentence: Insert "data" after "application" - In Section 3, step 3, it is stated that: "If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis," however, in Section 4, it is stated that: "Note that a server cannot choose to selectively reject early data at the TLS layer. TLS only permits a server to accept all early data, or none of it" - I guess this may be consistent (it will accept all data, but can selectively defer processing), but it is a bit confusing. - The attack in Section 4 is outlined as follows: "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." This seems a little convoluted - how would the attacker know, before the client has sent the first message, that it is what the client will send? Is the attacker's first message to a server instance intercepted from the client? If so, suggest making that clear. Thanks, -- Magnus