Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Bill Cox <[e-mail]>]

On Mon, Mar 14, 2016 at 12:23 PM, Ryan Hamilton <[e-mail]> wrote:

>
> On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <[e-mail]>
> wrote:
>
>> So, I don't think HTTP is generally safe against attacker-forced
>> replay, and would suggest great caution in allowing it.
>>
>
> It's worth keeping in mind this recent paper about Replay attacks against
> HTTPS <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN>.
> TL;DR: Attackers can already force a browser to replay requests basically
> at will. ​As a result, it's not clear that 0-RTT replay makes this
> situation worse.
>

Yay, this attack is finally published.  Now I can argue that stateful 0-RTT
resumption is secure enough to be the default 0-RTT connection mode in TLS
1.3.

Summary: The stateless 0-RTT modes currently described in the TLS 1.3 spec
are somewhat dangerous and should be used with caution and only by admins
who know what they are doing.  In contrast, 0-RTT resumption from session
caches has almost the same security as session resumption in TLS 1.2.
This should be the default 0-RTT mode in TLS 1.3, IMO, though stateless PSK
0-RTT should also be supported to allow advanced users to achieve even
higher performance.

The attack in the paper is important because it explains why I do not care
about the following attack, at least for HTTPS.  Suppose a company has
properly implemented 0-RTT resumption using session caches.  They support
strong client auth, full PFS, and would like to think they prevent replay
attacks.  This is a large company with non-synchronized session caches in
data centers around the world.  The has the following steps:

- The attacker captures 0-RTT packets intended for a local data center, and
holds onto them without letting them through (yet).
- The attacker also sends a copy of these packets to a remote data center.
- The remote data center, since it does not have the session cached, drops
to a 1-RTT handshake.
- The TLS layer in the client completes the 1-RTT handshake, and then
resends the 0-RTT data, as required by the TLS 1.3 spec.  This is accepted
by the remote data center.
- The attacker simultaneously sends the local data center the initial 0-RTT
packets, which are accepted by the local data center because the session is
in the cache.

If this were HTTPS traffic, this attack would work against TLS 1.2, because
the browser would resend the packets rather than the TLS layer.  In any
case attackers can replay _any_ HTTPS packet using the attack from the
paper.  This attack gains the attacker nothing new against HTTPS.

Because of this, I recommend that POST requests be allowed as 0-RTT data
over session-cache based stateful 0-RTT resumption, but not over stateless
0-RTT resumption.  The ability for an eavesdropper to infinitely replay
0-RTT data is specific to stateless 0-RTT resumption.

So, is there any application that cares about this attack?  Consider ssh
using TLS 1.3, with 0-RTT to accelerate how fast a user's command is
executed.  Clearly, we cannot allow the user's command to be executed
twice.  Even if the destination machine is a VM in the cloud, eventually
the connection is routed to the same virtual machine for both connections.
The session cache on that machine would get a hit on the first connection,
and execute the user's command.  The second set of packets would be
rejected because the session resume count would be wrong.  I see no way for
an attacker to succeed in a replay attack.

In general, I expect applications that are inherently sensitive to replay
(such as ssh) to terminate all TLS connections in the same place, where the
session cache is shared and synchronized.  Otherwise, random network errors
would be a huge problem.  Distributed applications such as HTTP that
terminate all over the place have had to deal with random replay issues
from the beginning, which is why no one is seems to be terribly upset by
the attack described in the paper.

Stateful 0-RTT resumed sessions can provide significant security guarantees
not offered by stateless 0-RTT:

- Effective, although imperfect, reply defense, which is good enough for
real-world deployment in most cases (are there any counter-examples?)
- Strong client auth works: even a replay attack will fail to forge a proof
of possession or cause a server to accept a signature twice.
- PFS is possible, unlike with DH 0-RTT, although it also can be done with
stateless PSK 0-RTT (a good reason to prefer PSK 0-RTT over DH 0-RTT)

The only new security concern I see compared to TLS 1.2 session resumption
is that the TLS layer sometimes will replay packets on its own without
involving the application layer.  This appears not to be a problem for
HTTPS and other protocols that already replay packets when there are
network errors.  For other applications, it should be carefully considered
before choosing to use session-ID based 0-RTT resumption, but I expect it
to be safe for protocols that already have to deal with noisy network
connections.

Bill