Re: [TLS] Rizzo claims implementation attach, should be interesting

Marsh Ray <marsh@extendedsubset.com> Tue, 20 September 2011 15:10 UTC

Return-Path: <marsh@extendedsubset.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 84FF921F8CDD for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 08:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599]
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 9+jHWU3CgUUq for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 08:10:45 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC2C21F8CD0 for <tls@ietf.org>; Tue, 20 Sep 2011 08:10:45 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1R620V-000C3f-6B; Tue, 20 Sep 2011 15:13:11 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F3A0E606C; Tue, 20 Sep 2011 15:13:08 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19Zjei0TvoNILnPc8o1b2n0YgH/4Qa5GHs=
Message-ID: <4E78AD85.4000504@extendedsubset.com>
Date: Tue, 20 Sep 2011 10:13:09 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: mrex@sap.com
References: <201109201445.p8KEju3B029762@fs4113.wdf.sap.corp>
In-Reply-To: <201109201445.p8KEju3B029762@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
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: Tue, 20 Sep 2011 15:10:46 -0000

On 09/20/2011 09:45 AM, Martin Rex wrote:
>
> But really, the underlying problem is letting an attacker reuse
> the very same symmetric key for his own data (adaptive chosen plaintext).
> Knowing the IV ahead of time can significantly improve an adequate choice
> of plaintexts, which is why the problem is worse in SSLv3 and TLSv1.0.
>
> But it should really be possible for browsers to seperate the TLS sockets
> that evil code can use and the sockets that victim code can use safely.

If only applications would set the 'evil bit' it would make a lot of 
things simpler!

But we can't add that as a new requirement for the existing protocols.

> Sharing cached TLS sessions is not a problem, each connection will
> derive their own traffic encryption and mac keys.  If Browsers can not
> seperate those network traffics, then there will be much more serious
> problems in the browser architecture to worry about than an attack
> that requires a cooperating network sniffer and malware running in
> your browser and a significant amount of network traffic between
> them.

People keep thinking of this in terms of a compromised endpoint attack. 
Bard 2004 even talks about requiring a "trojan horse plug in" to be 
practical. Bard 2006 reduces that to a malicious Java applet.

But I'm not convinced. Basic HTTP and browser behavior still leaves a 
lot of room for creativity. When the corresponding flaw was identified 
in IPsec it was not so easily dismissed on the basis that it required a 
compromised endpoint. From what I hear, TLS is used for VPN trunking too.

What about SMTP/POP/IMAP over TLS? They have similar amounts of known 
plaintext as HTTP, and an attacker may have the ability to control a 
large volume of messages, perhaps even in both directions.

- Marsh