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

Marsh Ray <> Tue, 20 September 2011 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84FF921F8CDD for <>; Tue, 20 Sep 2011 08:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9+jHWU3CgUUq for <>; Tue, 20 Sep 2011 08:10:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9CC2C21F8CD0 for <>; Tue, 20 Sep 2011 08:10:45 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.72) (envelope-from <>) id 1R620V-000C3f-6B; Tue, 20 Sep 2011 15:13:11 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id F3A0E606C; Tue, 20 Sep 2011 15:13:08 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19Zjei0TvoNILnPc8o1b2n0YgH/4Qa5GHs=
Message-ID: <>
Date: Tue, 20 Sep 2011 10:13:09 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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