Re: [TLS] Rizzo claims implementation attach, should be interesting
David Wagner <daw@cs.berkeley.edu> Fri, 23 September 2011 18:48 UTC
Return-Path: <daw@cs.berkeley.edu>
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 1D86321F8C83 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2011 11:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level:
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgg7LDYy0LtQ for <tls@ietfa.amsl.com>; Fri, 23 Sep 2011 11:48:25 -0700 (PDT)
Received: from taverner.cs.berkeley.edu (taverner.CS.Berkeley.EDU [128.32.153.193]) by ietfa.amsl.com (Postfix) with ESMTP id 955A021F8C7A for <tls@ietf.org>; Fri, 23 Sep 2011 11:48:25 -0700 (PDT)
Received: from taverner.cs.berkeley.edu (localhost.localdomain [127.0.0.1]) by taverner.cs.berkeley.edu (8.14.2/8.14.2) with ESMTP id p8NIp0TZ014159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Fri, 23 Sep 2011 11:51:00 -0700
Received: (from daw@localhost) by taverner.cs.berkeley.edu (8.14.2/8.14.2/Submit) id p8NIp0Ub014156 for tls@ietf.org; Fri, 23 Sep 2011 11:51:00 -0700
From: David Wagner <daw@cs.berkeley.edu>
Message-Id: <201109231851.p8NIp0Ub014156@taverner.cs.berkeley.edu>
To: tls@ietf.org
Date: Fri, 23 Sep 2011 11:51:00 -0700
Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 23 Sep 2011 11:51:22 -0700
Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 23 Sep 2011 18:48:27 -0000
I've been reading the discussion about this attack. Of course, until we see a full description of BEAST, it's hard to draw firm conclusions, but I want to suggest a slightly different perspective on some of the views I see mentioned here. I've seen the claim made that ~"it is inherently unsafe to mix trusted and untrusted content over the same encrypted channel, you should never do that, crypto protocols aren't intended to be secure against that"~. I do not think this is a fruitful or sensible way to think about things. Modern crypto protocols do aim to make it safe to mix trusted and untrusted content over the same channel. They aim to be secure against chosen-plaintext attack; and the notion of chosen-plaintext attacks is motivated exactly by ensuring it is safe to mix trusted and untrusted data over the same channel. The designers of SSL and TLS 1.0 presumably intended for SSL to be secure against chosen-plaintext attacks, but we've sinced learned that there is a subtle flaw that enables a successful chosen-plaintext attack. It is a surprise that they fell short of this natural goal and are vulnerable to chosen-plaintext attack (by the way, no need to bring up blockwise-adaptive attacks; blockwise-adaptivity is not needed). TLS 1.1 introduces revisions to fix this problem, and as far as we know, TLS 1.1 is secure against chosen-plaintext attack. The conventional wisdom until now has been that, while there are known chosen-plaintext attacks on TLS 1.0, they are not very serious in practice. As a result, there has not been much pressure to move to TLS 1.1. It may be time to reconsider that conventional wisdom. I don't think it makes sense to advocate "you should never send both trusted and untrusted content over the same crypto channel"; that advice leads to absurd results. Often dynamic web pages includes both trusted and untrusted content; are you going to advocate that no dynamic web page should sent over TLS? In my view, TLS had darn well better be secure in that threat model, and as far as we know, TLS 1.1 is. I've also seen claims on this list that ~"CBC mode is inherently insecure and should never be used"~. I think that's a little too broad. The problem with TLS 1.0 is not that it uses CBC mode and CBC mode is inherently insecure. Rather, the problem is that TLS 1.0 uses a special variant of CBC mode, one which turns out to be insecure against chosen-plaintext attack. In particular, TLS 1.0 uses "ciphertext block chaining", where the last ciphertext block is used as the next IV. This way of choosing the IV enables chosen-plaintext attacks. It is worth pointing out that the crypto-theory community has proven that, if CBC mode is used properly, it is secure against chosen-plaintext attacks. However, those proofs only apply to the standard form of CBC mode, where the IV is chosen randomly. The proofs do not apply to TLS 1.0's "ciphertext block chaining", and in fact, "ciphertext block chaining" is not secure: it is not IND-CPA secure. As long as you use CBC mode securely, these problems go away. TLS 1.1 does use a secure form of CBC mode. So I don't think it is accurate to suggest that CBC mode is necessarily insecure. In summary, I'd recommend: don't throw out the baby with the bathwater. We don't need to throw out CBC mode; TLS 1.1's use of CBC mode is fine. There's nothing wrong with sending both trusted and untrusted content over the same channel, as long as the crypto protocol is designed properly; and as best as we know, TLS 1.1 is fine for that. References for further reading: See Wei Dai's 2002 attacks on SSH and Bodo Moeller's extension of them to SSL and TLS 1.0: http://osdir.com/ml/ietf.secsh/2002-02/msg00049.html http://www.openssl.org/~bodo/tls-cbc.txt Those messages were clear that the implication of their attack is that SSL is not secure against chosen-plaintext attack, and the key enabler for their attack is that SSL's use of CBC mode chooses IVs unsafely. See also Greg Bard's paper, which extends those early observations and gave an early warning about the risks to SSL and TLS 1.0: http://eprint.iacr.org/2006/136
- Re: [TLS] Rizzo claims implementation attach, sho… David Wagner
- [TLS] Rizzo claims implementation attach, should … Tim Dierks
- Re: [TLS] Rizzo claims implementation attach, sho… Peter Gutmann
- Re: [TLS] Rizzo claims implementation attach, sho… =JeffH
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Steingruebl, Andy
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Marsh Ray
- Re: [TLS] Rizzo claims implementation attach, sho… Eric Rescorla
- Re: [TLS] Rizzo claims implementation attach, sho… Eric Rescorla
- Re: [TLS] Rizzo claims implementation attach, sho… Yoav Nir
- Re: [TLS] Rizzo claims implementation attach, sho… Marsh Ray
- Re: [TLS] Rizzo claims implementation attach, sho… Yoav Nir
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Marsh Ray
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Eric Rescorla
- Re: [TLS] Rizzo claims implementation attach, sho… Phillip Hallam-Baker
- Re: [TLS] Rizzo claims implementation attach, sho… Nico Williams
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Marsh Ray
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Geoffrey Keating
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… =JeffH
- Re: [TLS] Rizzo claims implementation attach, sho… Nico Williams
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Nico Williams
- Re: [TLS] Rizzo claims implementation attach, sho… Marsh Ray
- Re: [TLS] Rizzo claims implementation attach, sho… Nico Williams
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Eric Rescorla
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Yngve N. Pettersen
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Yngve N. Pettersen
- Re: [TLS] Rizzo claims implementation attach, sho… Martin Rex
- Re: [TLS] Rizzo claims implementation attach, sho… Yoav Nir