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

[Willy Tarreau <[e-mail]>]

Hello Magnus,

first, thanks for your review.

I'm having a few responses to some of your questions below :

On Wed, May 02, 2018 at 01:46:42AM -0400, Magnus Nyström wrote:
> 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")?

Not necessarily, as we could expect that some clients could find some
benefit in doing so (for example, proxies implemented by chaining a
server and a client, using a standard client library, and indicating
their ability to replay a request by setting this field when they
received the initial request using early data). I'm not saying there
is a valid case in sight, however there doesn't appear to be any
downside in doing so, so we'd rather not prevent interesting use cases
from emerging.

> 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?

No, because the request might have been received over early data by a
previous reverse proxy which itself uses TLS and early data to reach
the server. A typical use case will be a CDN frontend using early data
with the client and with the origin server. If the CDN presents an
Early-Data header field, the server knows that the request is unsafe
regardless of its own connection's state.

> 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.

Probably that we need to refine the wording. The point in section 3 was
to make it clear that early data may affect multiple requests (pipelining,
HTTP/2 multiplexing), and point 4 tries to clarify the fact that the TLS
layer provides you a data stream, part of which was received as early
data, and that the server has no choice but to consume them all or reject
them all.

> - 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.

Indeed, that was based on intercepted and replayed traffic. With an
individual hat, I agree that the example is a bit conflated. But the
point here was mostly to expose the risks that could happen by lazy
implementations that would take some shortcuts (like automatically
retrying on timeout for a client or a server accepting to process
unsafe early-data requests).

Thanks,
Willy