Subject: Fwd: New Version Notification for draft-thomson-http-replay-00.txt

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Jun 2017 17:27:24 +1000

HTTP folks,

Mark, Willy, and I have put together a draft that describes how HTTP
works with early data (or 0-RTT).

There's nothing revolutionary here, but we went through all the
intermediary scenarios and ensured that we have them covered.  The
main thing of interest is the technique we recommend for avoiding
exposure to replay attack.

--Martin

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 22 June 2017 at 16:50
Subject: New Version Notification for draft-thomson-http-replay-00.txt

Name:           draft-thomson-http-replay
Revision:       00
Title:          Using Early Data in HTTP
Document date:  2017-06-22
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-thomson-http-replay-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thomson-http-replay/
Htmlized:       https://tools.ietf.org/html/draft-thomson-http-replay-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-thomson-http-replay-00

Abstract:
   This document explains the risks of using early data for HTTP and
   describes techniques for reducing them.  In particular, it defines a
   mechanism that enables clients to communicate with servers about
   early data, to assure correct operation.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Jun 2017 17:32:11 +1000

FYI,

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:[email-masked]>.  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.

--Martin

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 22 June 2017 at 16:50
Subject: New Version Notification for draft-thomson-http-replay-00.txt

Abstract:

---

From: Mike Bishop <[email-masked]>
Date: Thu, 22 Jun 2017 17:38:24 +0000

I like most of it, but the second paragraph in 5 seems a little hand-wavy.  The gateway is supposed to "know" the server supports this new standard, which it can only fully do if it has received a 4NN in the past, which would only happen if it knew in the past, which....  Chicken, meet egg.

The gateway can make that presumption if the server accepts a 0-RTT connection from the gateway, but that presumes the gateway is maintaining enough state to do 0-RTT itself to all origin servers, which might be a big claim depending how much traffic it deals with to what set of origins.  (Or perhaps simply if the gateway has ever seen an early_data extension from the server in a NST message...?)

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, June 22, 2017 12:27 AM
To: HTTP Working Group <[email-masked]>
Subject: Fwd: New Version Notification for draft-thomson-http-replay-00.txt

HTTP folks,

Mark, Willy, and I have put together a draft that describes how HTTP works with early data (or 0-RTT).

There's nothing revolutionary here, but we went through all the intermediary scenarios and ensured that we have them covered.  The main thing of interest is the technique we recommend for avoiding exposure to replay attack.

--Martin

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 22 June 2017 at 16:50
Subject: New Version Notification for draft-thomson-http-replay-00.txt

Name:           draft-thomson-http-replay
Revision:       00
Title:          Using Early Data in HTTP
Document date:  2017-06-22
Group:          Individual Submission
Pages:          9
URL:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-thomson-http-replay-00.txt&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C3f8983c295e54bd6332f08d4b940c8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636337135275461846&sdata=PzRzDrRbGbyRBEkEJAMyTAUa5o1NDJTOxDUW6ShTEbg%3D&reserved=0
Status:         https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-thomson-http-replay%2F&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C3f8983c295e54bd6332f08d4b940c8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636337135275471854&sdata=FYx1nWuacnPEr8WsC6y0KxNyB3xKd0NSLH4IPsCtH8M%3D&reserved=0
Htmlized:       https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-thomson-http-replay-00&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C3f8983c295e54bd6332f08d4b940c8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636337135275471854&sdata=AVs8k1VgG9t7XSayv2PmP%2BdtT5lafiYsrJOj0xwbK7g%3D&reserved=0
Htmlized:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-thomson-http-replay-00&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C3f8983c295e54bd6332f08d4b940c8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636337135275471854&sdata=LLjMqfDYlMHTYg3fEFbIMm%2FsAQuiMqXOpUs%2F1cEH9uQ%3D&reserved=0

Abstract:

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Jun 2017 08:24:19 +1000

> I like most of it, but the second paragraph in 5 seems a little hand-wavy.  The gateway is supposed to "know" the server supports this new standard, which it can only fully do if it has received a…

I don't think that it is as hand-wavy as all that.  Keep in mind that
as a gateway for HTTPS, the gateway has the keys for the origin
server.  That means that there is a pretty strong relationship there.
The gateway can use that.  For instance, a CDN might delay requests
unconditionally unless their customer has provided an override that
enables immediate forwarding.

This is less of a chicken and egg issue even if the gateway is forced
to hold requests.  As we well know, the number of requests that can
fit into the first round trip is limited.  That's why header
compression is so useful.  Early data gives the client a little more
space for sending requests.  It's not much, but it's something.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 22 Jun 2017 22:40:03 +0000

Ah, just terminology, then.  I was reading "gateway" as "intermediary," not as "reverse proxy."  A reverse proxy is much more likely to have a close configuration relationship with its back-end server(s).

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, June 22, 2017 3:24 PM
To: Mike Bishop <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-thomson-http-replay-00.txt

> I like most of it, but the second paragraph in 5 seems a little hand-wavy.  The gateway is supposed to "know" the server supports this new standard, which it can only fully do if it has received a…

I don't think that it is as hand-wavy as all that.  Keep in mind that as a gateway for HTTPS, the gateway has the keys for the origin server.  That means that there is a pretty strong relationship there.
The gateway can use that.  For instance, a CDN might delay requests unconditionally unless their customer has provided an override that enables immediate forwarding.

This is less of a chicken and egg issue even if the gateway is forced to hold requests.  As we well know, the number of requests that can fit into the first round trip is limited.  That's why header compression is so useful.  Early data gives the client a little more space for sending requests.  It's not much, but it's something.

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 26 Jun 2017 16:03:24 +0900

Hi,

Thank you for working on the I-D.

This is a must-have and I am looking forward to seeing it
standardized. H2O will implement this specification.

One question: is the name `early-data` a good choice?

The reason I raise the concern is because what the header suggest is
if the endpoint has not yet seen a proof (i.e. ClientFinished). The
name "early-data" might be confusing since it may seem to imply _when_
the request has been received rather than the current state of the
connection.

Other than that I the draft looks good to me.

2017-06-22 16:32 GMT+09:00 Martin Thomson <[email-masked]>:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 26 Jun 2017 10:01:31 +0200

Hi Kazuho,

> the request has been received rather than the current state of the

You mean that you'd prefer something indicating that there were unsafe
(ie not yet validated) early data in fact, that's it ?

Willy

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Jun 2017 10:32:28 -0500

Hi Martin,

On 06/22/2017 02:32 AM, Martin Thomson wrote:
> 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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Jun 2017 10:44:19 -0700

Thanks for your thoughts Ben,

On 26 June 2017 at 08:32, Benjamin Kaduk <[email-masked]> wrote:
> 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.

https://github.com/martinthomson/http-replay/pull/17

(You also mentioned things like cookies and whether we might have
other guidance for how clients might restrict what they send.  We
currently focus on request methods, and take the extremely
conservative position of recommending only "safe" methods.)

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

This is actually intentional, but we should say that explicitly.

https://github.com/martinthomson/http-replay/issues/16

> strateg(ies) (item 4).

I think that it's important to mention, if only because a lot of the
other defenses rely on that point you made earlier about reducing the
potential billions down to something more manageable.  It's especially
relevant when you are worrying about leakage through side-channels.

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

That might be too subtle in the sense that it relies on someone making
a non-obvious decision about how to handle replays.  Hopefully we have
provided enough information for those people to make the right
decision, because I can't think of any easy way to first introduce the
notion of treating requests differently across a different server
instances and then the consequences of that choice.

> reject the risk of replay for a given request, and the client being able to
> decide on risk when creating requests.
>
> 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.)

I think that it is accurate, though as you correctly observe, what
people think of as state-changing side-effects is sometimes far more
limited in scope.  That's dangerous.  I'm proposing a tweak to the
language, but thinking about whether there needs to be more exposition
on this point.

https://github.com/martinthomson/http-replay/pull/18

> I would clarify that the inability to selectively reject early data is at
> the TLS layer,

Done, thanks.

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

There are plenty of cases where a client knows that a request is safe
to attempt, and a server is always able to make the same
determination.

> Also, what might
> cause a client to abandon those requests?  Should we give
> examples/reasoning?

This is totally generic, and so specific reasons for abandoning are
hard to scope properly.

> (Token binding is one thing that comes to mind, as the
> requests would need to be regenerated with the proper bindings;

Ahh, 0-RTT token binding is a horror.  This is why generally the
"start over" thing is important.  I think that the best way to
implement token binding is to decorate requests as they get written to
the socket, so that the header field is not (incorrectly) attached to
the thing that is retried.

> 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

This ambiguity was intentional from my perspective.  On the one hand,
I don't think that rejection of early data is good grounds for
deciding to abandon a request and the "close the tab" example is a
better basis for abandoning a request.  But I also recognize that
retrying does create that one-time replay exposure and I didn't want
to expressly prohibit deciding to abandon requests if early data is
rejected.

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

Correct.  The unique key might have value, but we're looking for the
minimum viable solution here and I can't convince myself that the
unique key adds enough to warrant standardizing something like that.

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

TLS already covers this adequately:

> If the server rejects the “early_data” extension, the client application MAY opt to retransmit early data once the handshake has been completed. Note that automatic re-transmission of early data could result in assumptions about the status of the connection being incorrect. For instance, when the negotiated connection selects a different ALPN protocol from what was used for the early data, an application might need to construct different messages. Similarly, if early data assumes anything about the connection state, it might be sent in error after the handshake completes.

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

I'm not happy with this text but the mention of "max_early_data_size"
was to specifically direct attention to the resource commitment
constraint.

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 27 Jun 2017 07:26:10 +0900

Hi Willy,

> (ie not yet validated) early data in fact, that's it ?

Yes. That was my intention.

-- 
Kazuho Oku

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Jun 2017 14:02:33 -0500

> conservative position of recommending only "safe" methods.)

Hmm, "extremely conservative" seems a bit subjective; from where I sit
the current position is more "middle-of-the-road" and "extremely
conservative" would be along the lines of "you get 1 GET, no cookies,
sent atomically".  Not that I am arguing for the draft to become more
lenient, of course!

> relevant when you are worrying about leakage through side-channels.

Well, I hope that TLS ends up mandating something that is not the
potential billions, in which case it's less of an issue here. Of course,
if TLS does not make such a mandate, we could still do so here ...

> instances and then the consequences of that choice.

How would you feel about adding an additional sentence, something like
"Even if a given server responds with 4NN (Too Early), replay of that
request may still be possible if a different server (or the same server
at a different time) makes a different risk assessment and is willing to
process the request."?

> https://github.com/martinthomson/http-replay/pull/18

I'll take a look there, thanks.

> This is totally generic, and so specific reasons for abandoning are

Agreed.  Do you want to mention ", whether specifically due to the
rejection or early data or otherwise" to make the genericity super-clear?

> "start over" thing is important.  I think that the best way to

Yes.  I don't have any suggested text right now that would emphasize
this more, but there may be room for improvement in this area.

> the thing that is retried.

In an async world, I have to agree.  (Though this topic is really more a
matter for tokbind than httpbis.)

> to expressly prohibit deciding to abandon requests if early data is

I guess this mostly answers my above question.

> TLS already covers this adequately:

You mean people actually read the references? ;)
(I agree that it's probably fine to leave this text as-is.)

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 28 Jun 2017 23:00:26 +0300

> if TLS does not make such a mandate, we could still do so here ...

Well, the stuff to ensure that you don't get billions (or millions) of
replays is only SHOULD in the current proposal at TLS WG...

> this more, but there may be room for improvement in this area.

I think tokbind mandates strict global anti-replay for 0-RTT token
binding. Because there would be an attack otherwise.

-Ilari

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Jun 2017 15:51:07 -0500

> replays is only SHOULD in the current proposal at TLS WG...

Yeah, I have a comment staged about that on that PR; just not done
reviewing the whole thing yet.

> binding. Because there would be an attack otherwise.

Right.  Well, either that or just don't do 0-RTT token binding at all
(my preference), but there may be enough demand for it to get rough
consensus there.

-Ben