Re: Working Group Last Call for Using Early Data in HTTP

On Sat, Nov 25, 2017 at 5:44 PM, John Mattsson
<john.mattsson@ericsson.com> wrote:
> Read this for the first time. Well-written and useful document.
>
> - Abstract: “This document explains the risks of using early data for HTTP ...”
> Very little explanations of risks in the document. I think more explanation and maybe some examples would be helpful for the readers of this document.

Does this work better?

Using TLS early data creates an exposure to the possibility of a replay attack.
This document defines mechanisms that allows 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.

-- https://github.com/httpwg/http-extensions/pull/430/files

> - Section 1: “one or two round trip delay”
> Should this be “one or two round trip delays”?

I think that in context this is grammatically correct.

> - Section 2: “concatenated with other application”
> Should this be “concatenated with other application data”?

Yes.

> - Section 1: “The primary risk of using early data is that an attacker might capture and replay the request(s) it contains.”
>
> I think the it would be very good to explain what replay means in this case, especially as the reader might be someone without detailed knowledge of TLS 1.3. While replay in some cases means more than duplication, replay in normal language means duplication and anti-replay are in most cases synonym with mechanisms mitigating duplication. I suggest something like:
>
>  “The primary risk of using early data is that an attacker might capture and replay the request(s) it contains. The attacker might delay, reorder, and/or duplicate requests.”

I think that replay in this context is specifically only means
duplication.  Delaying and reordering are risks that are assumed when
requests are put on different connections, and more importantly, delay
and reorder are not new risks here (they are possible with any
combination of HTTP and TLS versions).

> - Section 3: “TLS [TLS13] mandates”
> Doesn’t TLS 1.3 says “SHOULD implement either the single-use tickets or ClientHello recording techniques”?

It goes a lot further than that.  It mandates the use of anti-replay,
though it more strongly recommends those particular techniques.

> - Section 3: “It is RECOMMENDED that origin servers allow resources to explicitly
> configure whether early data is appropriate in requests.  Absent such
> explicit information, they SHOULD mitigate against early data in
> requests that have unsafe methods, using the techniques outlined
> above.”
>
> “unsafe methods” -> “not safe from side-effects” following the reason above.

I've rewritten that text in response to Stephen.  That removed the
"unsafe" bit.  See https://github.com/httpwg/http-extensions/pull/428

Received on Sunday, 26 November 2017 23:07:01 UTC