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

Bill Cox <> Mon, 14 March 2016 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9745C12D7AA for <>; Mon, 14 Mar 2016 15:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EmpLh5FMLQ2c for <>; Mon, 14 Mar 2016 15:03:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C1B712D7A4 for <>; Mon, 14 Mar 2016 15:03:25 -0700 (PDT)
Received: by with SMTP id ig19so1316685igb.1 for <>; Mon, 14 Mar 2016 15:03:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wGcrA9FuyzOng8vwDM49Wlk7VpGq30WaqihICp4fqS4=; b=mImv2A56xjtkONpoIDMOxD1V4g2jtFywu7I+ncu05Qg8RzYGFR9Bkvu19C4OH0zx+e mRK1ctl5fun6mFUjZ4U+Y6MIaEOTMfgIT96wrkDwvV3t4E9sRHX1KaEI5h6Dm/iiATjW riUwWAhWfWFt09lE/u39HSbjJxV4AHQkNFXSFB8TJXBtjFqo2sMOiICSSiTzM0MfiKck MkwGZRmdS0r+hQ+a0VVfxRRpfcalNPWOGJ00YIbjqrtpmNVYStBxLeC7yz3g7x5b0Xci OTT1IR02ZHRGoov8oCP0KMkxbspCL3X0Q86wwDHJyXbO4jbUwlhvonGh8tMWDPJkJJBU WGfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wGcrA9FuyzOng8vwDM49Wlk7VpGq30WaqihICp4fqS4=; b=jjGFxOkOPOg648DCZhh938c/OFZ42OOjJ7v+1z1Gm+v/qu7qei6ENpMTKD2EUSx11h rXiO6T+yFjvXOo/caFe5WGkcjHOX+IPEO3kIG/gvzDvWs738q5YWw/Rv0TZ/7EbNLTW1 G6nlajPFhute/aSZUQj3JeBUhMARldoH3mqVuo2+wyCGZ+jojPtcDFQOMUmkM5yhIOef +dAYr6mn2XDKByPaM1NothQE0NZS4kFJC206vEC8nyU6uQEzB3MbjXnZvdlft7g9Dd5k 6ZxTLlsxSVcFLFZdi4lkfdXH3ChmehO1Idq0FamQsYJ/yzClEw8nk0GQG3wHB4t7NctL 188w==
X-Gm-Message-State: AD7BkJL+8zM7ps8Z1V29T7YhXA0tx305x0iLmqI61EHrsQrv1acDGhlNZ+BMU/1K2rRJdM2OEzfBriZxHPNRK8OJ
MIME-Version: 1.0
X-Received: by with SMTP id g19mr20444571igt.4.1457993004258; Mon, 14 Mar 2016 15:03:24 -0700 (PDT)
Received: by with HTTP; Mon, 14 Mar 2016 15:03:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <m2egbcq3f0.fsf@localhost.localdomain> <>
Date: Mon, 14 Mar 2016 15:03:23 -0700
Message-ID: <>
From: Bill Cox <>
To: Ryan Hamilton <>
Content-Type: multipart/alternative; boundary=047d7bdc15b21af075052e09736c
Archived-At: <>
Cc: Geoffrey Keating <>, "" <>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Mar 2016 22:03:27 -0000

On Mon, Mar 14, 2016 at 12:23 PM, Ryan Hamilton <> wrote:

> On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <>
> 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 <>.
> 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

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