[secdir] Secdir review of draft-ietf-httpbis-replay

[Magnus Nyström <[e-mail]>]

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