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

[Martin Thomson <[e-mail]>]

Yes, thanks Magnus,

I think that Willy answered the primary concerns.  I'm not sure that there
is anything actionable in those, but if you have a suggestion for
improvement, that would be appreciated.

> > - Section 2, first sentence: Insert "data" after "application"

This is fixed in the editor's copy (long story there, but the draft you
reviewed was *slightly* out of date).

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

When I went to look at this, I noticed that we don't really explain that
rejecting 0-RTT is possible.  That's an important option, even if it is
pretty severely limited.

So I added that:
    2.  The server can reject early data.  A server cannot selectively
        reject early data, so this results in all requests sent in early
        data being discarded.

Full change at: https://github.com/httpwg/http-extensions/pull/602

In doing so, I think that the context needed to interpret step 3 (now step
4) is available.

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

Yeah, maybe this alternative is better:
    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.

Details at: https://github.com/httpwg/http-extensions/pull/603