Re: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt

Hi Martin,

On 06/22/2017 02:32 AM, Martin Thomson wrote:
> FYI,
>
> Mark, Willy, and I have put together a draft that describes how HTTP
> works with early data (or 0-RTT).
>
> The main thing of interest is the technique we recommend for avoiding
> exposure to replays, particularly given that HTTP is often
> intermediated.
>
> If you have specific comments about the draft, I'd appreciate it if
> you could take those to the HTTP working group
> <mailto:ietf-http-wg@w3.org>.  Of course, you should feel free to
> start another massive thread about the various ways in which you think
> early data represents the beginning of the end for modern
> civilization.  That seems to be the usual reaction to this sort of email.
>

First off, a big thank you for writing this up -- it's been a glaring
omission from ongoing work for a long time, and it's good to get
something concrete in place to work from.

I won't claim that early data represents the beginning of the end for
modern civilization, but I do think that it's worth mentioning on this
list the qualitative distinction between tens of replays and billions of
replays that was made on the TLS list.  It may or may not be necessary
to mention that in the document itself, but it does shape at least my
thinking about these issues.  In a world where early data could be
replayed millions or billions of times, enabling various sorts of
side-channel attacks, I would think very hard about placing more severe
limitations than those specified in this document on what HTTP messages
can be sent over early data.  I'd prefer to not live in that world, of
course, but perhaps sending secure cookies would be inappropriate and
the permitted methods would need to be further restricted, or even early
data limited to a single self-contained request that is sent atomically
and must not spill over into 1-RTT data.

I'm also a little surprised that there is no discussion of whether a
request is permitted to be sent partially in 0-RTT and partially in
1-RTT data and what the semantics are for such a request -- it just
talks about "requests" that are sent "immediately", "requests in early
data", and the like.

I do have some more specific comments about the draft as well.

In section 2, I'm not sure that we need to mention the TLS-native
strateg(ies) (item 4).  There is also some potential subtlety in item
(3), relating to whether the server decides to respond with 4NN (Too
Early) in a deterministic fashion *across all servers that might handle
the request* based solely on the contents of the request (which is a
very safe strategy) or also includes information about the rate of
incoming requests/etc. in the decision (which could lead to some
successful replays).

I think you have some good text about the server being able to accept or
reject the risk of replay for a given request, and the client being able
to decide on risk when creating requests.

However, I'm not sure this claim is accurate:

   [...] In general, if a request does not have state-
   changing side effects on a resource, the consequences of replay are
   not significant.

with respect to the feasibility of side-channel attacks on the preparation of the response.  (And the hopefully obvious note that affecting/determining whether or not a resource is in a particular cache is a side effect.)

In:

   Note that a server cannot choose to selectively reject early data.
   TLS only permits a server to accept all early data, or none of it.
   Once a server has decided to accept early data, it MUST process all
   requests in early data, even if the server rejects the request by
   sending a 4NN (Too Early) response.

I would clarify that the inability to selectively reject early data is at the TLS layer, since the word "reject" is also used later on to describe the 4NN (Too Early) response.  Or perhaps just drop the first sentence entirely.

In section 3, is there a good justification for leaving as only SHOULD NOT send unsafe methods in early data?  If this is something security sensitive, it would seem that there is some rationale for making it mandatory.

Similarly to above, for:

   If the server rejects early data, a client MUST start sending again
   as though the connection was new.  For HTTP/2, this means re-sending
   the connection preface.  Any requests sent in early data MUST be sent
   again, unless the client decides to abandon those requests.

we could clarify that this is for TLS-level rejection.  Also, what might cause a client to abandon those requests?  Should we give examples/reasoning?  (Token binding is one thing that comes to mind, as the requests would need to be regenerated with the proper bindings; perhaps I am asking for clarity on having the decision to abandon the request be specifically due to the early data rejection vs. just the client is not interested in the response anymore (say, because the user closed a browser tab).  This potentially ties into the MUST retry on 4NN (Too Early) part, with respect to the "not interested in the response anymore" scenarios.

Section 4.1 adds the "Early-Data" header; just to confirm my understanding, this is just about ensuring that the semantic difference between early data and regular data gets conveyed properly through multiple hops -- it does not try to present a uniquifying key as Cf-0rtt-Unique did, so "Early-Data" can actually succeed in its designated role.  (Well, presuming that implementations comply with the spec, I suppose.)

Section 4.2 adds the 4NN (Too Early) status code, but perhaps is also papering over some subtleties with:

   Clients (user-agents and intermediaries) that sent the request in
   early data MUST automatically retry the request when receiving a 4NN
   (Too Early) response status code.  Such retries MUST NOT be sent in
   early data, and SHOULD NOT be sent if the TLS handshake on the
   original connection does not successfully complete.

Similarly to the above, what if a client decides it no longer cares about getting a response to that request?  And "retrying the request" can require regenerating some values if TLS exporter values are used (e.g., token binding), which might be worth mentioning.   There is also some small potential for reader confusion in that retries can (but perhaps should not) be initiated by the TLS stack on 0-RTT negotiation failure, and also by the HTTP stack on 4NN (Too Early), but only one of those will come into effect for any given request.


These comments aside, I think this is a topic that the WG should take on and would support adopting this document as a starting point for such work.


Editorial nit:

In section 2:

   A server can limit the amount of early data with the
   "max_early_data_size" field of the "early_data" TLS extension.  This
   can be used to avoid committing an arbitrary amount of memory for
   deferred requests.  A server SHOULD ensure that when it accepts early
   data, it can defer processing of requests until after the TLS
   handshake completes.

"it can defer processing" might mention that this means the server must have sufficient resources available to store the buffered requests.

-Ben