Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
Bill Cox <waywardgeek@google.com> Mon, 14 March 2016 22:03 UTC
Return-Path: <waywardgeek@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9745C12D7AA for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 15:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmpLh5FMLQ2c for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 15:03:25 -0700 (PDT)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1B712D7A4 for <tls@ietf.org>; Mon, 14 Mar 2016 15:03:25 -0700 (PDT)
Received: by mail-ig0-x234.google.com with SMTP id ig19so1316685igb.1 for <tls@ietf.org>; Mon, 14 Mar 2016 15:03:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.50.66.179 with SMTP id g19mr20444571igt.4.1457993004258; Mon, 14 Mar 2016 15:03:24 -0700 (PDT)
Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 15:03:23 -0700 (PDT)
In-Reply-To: <CAJ_4DfQJGCptCP3T-JZma5JKoeHjgJqux6Z-qCLEeQN0tbd79w@mail.gmail.com>
References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> <CAAF6GDdc8JxH1Utms2ms6YFm7p+2SGqCChgfVd6-6m2So2_TSQ@mail.gmail.com> <m2egbcq3f0.fsf@localhost.localdomain> <CAJ_4DfQJGCptCP3T-JZma5JKoeHjgJqux6Z-qCLEeQN0tbd79w@mail.gmail.com>
Date: Mon, 14 Mar 2016 15:03:23 -0700
Message-ID: <CAH9QtQHCiX8Ox9tPg11FCKjSdNXjupJ7g83O3rtieROFWFcTwg@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: Ryan Hamilton <rch@google.com>
Content-Type: multipart/alternative; boundary="047d7bdc15b21af075052e09736c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/zkPqajUTri1OAJkuSQK22l_UdzY>
Cc: Geoffrey Keating <geoffk@geoffk.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2016 22:03:27 -0000
On Mon, Mar 14, 2016 at 12:23 PM, Ryan Hamilton <rch@google.com> wrote: > > On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <geoffk@geoffk.org> > 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
- [TLS] analysis of wider impact of TLS1.3 replayab… Stephen Farrell
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Stephen Farrell
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Stephen Farrell
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Salz, Rich
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Yoav Nir
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Salz, Rich
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Stephen Farrell
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Kurt Roeckx
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Salz, Rich
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ilari Liusvaara
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Andrei Popov
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Scott Schmit
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Erik Nygren
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Harlan Lieberman-Berg
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ilari Liusvaara
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Nikos Mavrogiannopoulos
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Kyle Nekritz
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Viktor Dukhovni
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Subodh Iyengar
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Watson Ladd
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Subodh Iyengar
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ilari Liusvaara
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Geoffrey Keating
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ryan Hamilton
- [TLS] Splitting all stateless 0RTT into its own d… Dave Garrett
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Salz, Rich
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] Splitting all stateless 0RTT into its o… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Geoffrey Keating
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ryan Hamilton
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ryan Hamilton
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Kyle Nekritz
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] Splitting all stateless 0RTT into its o… Ilari Liusvaara
- Re: [TLS] Splitting all stateless 0RTT into its o… Viktor Dukhovni
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Hubert Kario
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Martin Thomson
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Hubert Kario