Subject: [TLS] Idempotency and the application developer

From: Watson Ladd <[email-masked]>
Date: Thu, 4 May 2017 16:35:10 -0700

Dear all,

Applications have always had to deal with the occasional replay,
whether from an impatient user or a broken connection at exactly the
wrong time. But they've generally been rare, so human-in-the-loop
responses work. Order the same book twice? Just return one of them,
and if you get an overdraft fee, ouch, we're sorry, but nothing we can
do.

0-RTT is opt-in per protocol, and what we think of per application.
But it isn't opt-in for web application developers. Once browsers and
servers start shipping, 0-RTT will turn on by accident or deliberately
at various places in the stack.

At the same time idempotency patterns using unique IDs might require
nonidempotent backend requests. But this is an easier problem than if
we had nonidempotent brower requests: backends are much more
controlled.

If you are willing to buffer 0-RTT until completion before going to
the thing that makes the response, you can handle this problem for the
responsemaker. This will work for most applications I can think of,
and you need to handle large, drawn out requests anyway. This sounds
like it would work as a solution, but I am sure there are details I
haven't discovered yet.

In conclusion I think there is some thought that needs to go into
handling 0-RTT on the web, but it is manageable. I don't know about
other protocols, but they don't have the same kinds of problem as the
web does with lots of request passing around. Given the benefits here,
I think people will really want 0-RTT, and we are going to have to
figure out how to live with it.

Sincerely,
Watson Ladd

---

From: Derrell Piper <[email-masked]>
Date: Thu, 4 May 2017 17:38:38 -0600

> On May 4, 2017, at 5:35 PM, Watson Ladd <[email-masked]> wrote:
> 
> 0-RTT is opt-in per protocol

…and at the end of the day, that’s the only reason I’d agree to this.

Derrell

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 4 May 2017 16:47:42 -0700

On Thu, May 4, 2017 at 4:35 PM, Watson Ladd <[email-masked]> wrote:

> wrong time.

Unfortunately this isn't the case :( Not all applications are user-driven
in that way, and some are very careful about how they retry. In the review
I go through the example of an update to an eventually consistent data
store. In that case, the application will typically try to update and if
that update times-out, it will wait a time period, check for a conflict or
a success, and only then retry.  At no point is a replay, normal or
expected.

One could argue that Zero-RTT is not for applications like this, but why
not? They certainly do benefit from the speed-up. And so in the review I go
through reasons why it is likely that they will use it anyway, ranging from
how subtle and hard the review is, to inadvertent enabling of the feature
on something like an L4 TLS proxy which has no awareness of the underlying
protocol.

But they've generally been rare, so human-in-the-loop
> at various places in the stack.

+1!

> like it would work as a solution, but I am sure there are details I

I think you're right; and we could enforce in TLS by encrypting 0-RTT under
a key that isn't transmitted until 1-RTT. But this would also defeat the
point of the speed-up; especially for CDNs. It really does speed things up
for them to be able to send the request to the origin right away.

> figure out how to live with it.

+1 I think it's manageable too. Just have servers check for dupes :)

-- 
Colm

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 18:58:12 -0500

> 0-RTT is opt-in per protocol, and what we think of per application.

Yes.

> at various places in the stack.

It should be up to servers whether a request is allowed with 0-rtt.

If the server doesn't allow a given 0-rtt request and causes the client
to do one round trip, does it matter that the client tried with 0-rtt?
What can an attacker do?  Can they replay that 0-rtt request?  Surely
not, since the server didn't take it.  And presumably other servers in
the same cluster will make the same decision.

> figure out how to live with it.

Yes.

In particular there has to be a way, either in-TLS, or at the
application layer, to force an extra round-trip to confirm that the
0-rtt data was not an unintended replay.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Thu, 4 May 2017 17:18:32 -0700

> It should be up to servers whether a request is allowed with 0-rtt.

Which server?  It's possible that the backhauls from the server the
TLS connection is made to to the server actually responding to the
request do not distinguish 0-RTT from other data. Opportunity for
administrative bloopers is immense: even if the responding server
rejects 0-RTT, the server proxying requests won't necessarily know
that inline as it is reusing the connection.

<chop>
> 0-rtt data was not an unintended replay.

One can always reject... unless I am misunderstanding the suggestion.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Erik Nygren <[email-masked]>
Date: Thu, 4 May 2017 21:31:55 -0400

> that inline as it is reusing the connection.

+1

By the time the client has sent 0-RTT data the complexity mess
has already and it may be too late to avoid some of the potential
vulnerabilities.

Just as an example of a type of attack:  attacker replays 0-RTT messages.
If the server accepts some (sends larger responses) and rejects others
(sends smaller
responses) than that tells you something about the messages
and the attacker you can tell which client requests might have been
replay-safe
and which ones were not.

      Erik

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 5 May 2017 03:22:56 +0000

> and if you get an overdraft fee, ouch, we're sorry, but nothing we can

Very few applications have been designed with deliberate malicious “intelligent” interference in mind. Probably none among those that delegate their communications security to a “security protocol” such as TLS or IPsec. After all, a big selling point of using (somebody else’s) security protocol/implementation is that the security responsibilities are “outsourced” to that other layer/entity/<you got the idea>.

Haven’t you heard this: “I don’t know how to secure my pipe, and I don’t have to - I use TLS for that”.

So far the consequences have been rather mild, not much worse than what Watson showed as examples to illustrate his point. But it is changing, and not for the better.
 
Summary: it is not good to deliberately ignore malicious replays.

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 22:36:53 -0500

> that inline as it is reusing the connection.

The one that terminates TLS.  If that's a reverse proxy, then it has to
know or not allow 0-rtt.  That means that by default reverse proxies
can't accept 0-rtt, and they have to know a lot about the application in
order to accept it (or else let the server know that 0-rtt was used and
let the server give the client an appropriate error if that's not
acceptable).

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 4 May 2017 23:11:29 -0500

> let the server give the client an appropriate error if that's not

I'm very skeptical that this position would survive into real-world
deployments.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 4 May 2017 23:14:01 -0500

> One can always reject... unless I am misunderstanding the suggestion.

I'm pretty sure Nico still wants data-dependent reject, which is not
workable in the general case.  (See the discussion of reverse proxies.)

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 4 May 2017 23:22:47 -0500

> like it would work as a solution, but I am sure there are details I

The server is allowed to buffer the 0-RTT data while processing it and
delay a response until the handshake is completed, yes.  (I think this
is the "way to force 1-RTT at the application layer" that Nico wants.) 
It removes the latency benefits of 0-RTT [for that request] and might be
annoying to implement with APIs that only give you a single data stream
(but probably not too bad), but the application layer at the server has
the capability to solve these idempotency/replay problems. 
Unfortunately, we are the TLS layer and cannot assume that we control or
can cooperate with the application.  Which leads right back to the
"application profile is required" bit, of course.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 23:52:59 -0500

> I'm very skeptical that this position would survive into real-world

Which part?

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 23:55:09 -0500

> workable in the general case.  (See the discussion of reverse proxies.)

What I want?  I'm saying that 0-rtt requires much care.  Specifically it
requires any of:

 - replay caching
 - not allowing 0-rtt for non-idempotent data (there are several ways to
   "not allow" 0-rtt in this case)

Take your pick.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 May 2017 00:04:14 -0500

>> I'm very skeptical that this position would survive into real-world

No matter what we way here, there will be reverse proxies deployed on
the internet in the next 5 years that blindly accept 0-RTT knowing
nothing about the application and not letting the server know that 0-RTT
was used.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Fri, 5 May 2017 00:04:13 -0500

> is the "way to force 1-RTT at the application layer" that Nico wants.) 

I'm not up on the details of how 0-rtt works in TLS 1.3.  I don't know
if there's a way for the server to cause a round-trip to occur, nor if
there's a way for the client to then confirm the 0-rtt data in that
round-trip.

I do think having such functionality would be very helpful for cases
where the server runs a) without a replay cache, and b) can accept
idempotent and non-idempotent requests.

I think always requiring a replay cache is not likely to work out in
practice.

> It removes the latency benefits of 0-RTT [for that request] and might be

Because [for that request] there are no benefits of 0-rtt.

> "application profile is required" bit, of course.

Yes, sure, but the application profile rubber has to meet the road.
That usually means that the devil is in the APIs.

An application that wants a "dumb secure socket"... just can't have
0-rtt.

HTTP should be trivial to profile... if only GET weren't abused here and
there.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 May 2017 00:15:46 -0500

> there's a way for the client to then confirm the 0-rtt data in that

The server is blindly carrying data for the application.  The
application can decide to not send any 0.5-RTT data in response to the
0-RTT data, and wait for the regular 1.5-RTT response, if it wants.

> idempotent and non-idempotent requests.

If we presume knowledge of (b) then we are forced to consider it at the
application layer; a TLS-layer signal would be pretty awkward to manage,
and an application-layer signal (or delayed response) seems much more
reasonable.

> I think always requiring a replay cache is not likely to work out in

I agree.  I don't think we should make a claim that 0-RTT data is
safe/non-replayable by virtue of requiring that servers implement a
replay cache; it's doing consumers a disservice if we expect that there
will be servers that don't implement the strict anti-replay measures.

Yes.

> HTTP should be trivial to profile... if only GET weren't abused here and

You might look at
https://tools.ietf.org/html/draft-nottingham-httpbis-retry-01 , though
I'm no longer confident that's actually the Nottingham document I'm
thinking of :(

-Ben

---

From: Bill Frantz <[email-masked]>
Date: Fri, 5 May 2017 08:31:53 -0700

On 5/4/17 at 4:47 PM, [email-masked] (Colm MacCárthaigh) wrote:

>a key that isn't transmitted until 1-RTT.

This might be a generally useful pattern for 0-RTT use cases 
that are trying to get large quantities of data to the server quickly.

BTW, I expect to see lots of security bugs due to 0-RTT.

<cynic>But the Internet and computer operating systems are 
insecure anyway.</cynic>

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | The first thing you need when  | Periwinkle
(408)356-8506      | using a perimeter defense is a | 16345 
Englewood Ave
www.pwpconsult.com | perimeter.                     | Los Gatos, 
CA 95032

---

From: Nico Williams <[email-masked]>
Date: Fri, 5 May 2017 11:28:00 -0500

> nothing about the application and not letting the server know that 0-RTT

Really?  They already exist and are already deployed?

If so... I... have nothing good to say about that right now, so I'd
better say no more.

Nico
--