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

Marsh Ray <marsh@extendedsubset.com> Tue, 20 September 2011 21:45 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 2C8C01F0CA5 for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 14:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.581
X-Spam-Level:
X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, GB_I_LETTER=-2]
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 EHnMd5OtgSaZ for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 14:45:27 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0271F0C91 for <tls@ietf.org>; Tue, 20 Sep 2011 14:45:27 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1R68AU-000FLK-9v; Tue, 20 Sep 2011 21:47:54 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E55DF606C; Tue, 20 Sep 2011 21:47:51 +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: U2FsdGVkX18jSs2XYJU6/7C8+OWCZoCkrJOiU4JqRLI=
Message-ID: <4E790A09.7020007@extendedsubset.com>
Date: Tue, 20 Sep 2011 16:47:53 -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: <201109202131.p8KLVpd0024045@fs4113.wdf.sap.corp>
In-Reply-To: <201109202131.p8KLVpd0024045@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org, asteingruebl@paypal-inc.com
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 21:45:28 -0000

On 09/20/2011 04:31 PM, Martin Rex wrote:
>
> Independent TLS connection states (even for the same cached TLS session)
> do not share traffic encryption and mac keys, so these are protected
> from each other.
>
> But when you start multiplexing adaptively chosen plaintext from
> an attacker with data from a victim, then you're creating an oracle.

It's only an oracle if there is information revealed to the attacker. If 
that's the case, it should be considered a cryptographic weakness.

> For TLS cipher suites using block ciphers in CBC mode, there is
> a fixed encryption key for all blocks of data.  Now if the
> block of data for which the attacker wants to recover the exact
> plaintext is sufficiently short (e.g. DES-based = 64-bit), and this
> block of contains a small amount of unknown entropy, and the attacker
> is permitted sufficient guesses at the original plaintext, the attacker
> may perform a guessing attempt at that unknown victim data.

Yeah CBC sucks, especially with predictable IVs.

It's a weakness.

> It was not a design requirement at that time, so that property does
> not exist in the original SSLv3 (and TLS) design.  When cipher suites
> with stream ciphers are not affected, then this is a lucky coincidence,
> not a result of a conscious design (based on a requirement).

Well where does that reasoning end?

If a defect were found in TLS which could be exploited using long 
strings of the letter 'A', would you say that the protocol was never 
"designed to resist long strings of the letter 'A' attacks"?

This protocol is something called "IETF Transport Layer Security". It's 
not "Security for Data That M. Rex Feels Web Browsers Should Be Able to 
Transport Securely". :-)

- Marsh