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

Martin Rex <mrex@sap.com> Tue, 20 September 2011 15:19 UTC

Return-Path: <mrex@sap.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 64CA821F8B75 for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 08:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level:
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 IPn2aDWovAxe for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 08:19:05 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAE821F8B71 for <tls@ietf.org>; Tue, 20 Sep 2011 08:19:05 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8KFLSY1028757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2011 17:21:28 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Tue, 20 Sep 2011 17:21:27 +0200 (MEST)
In-Reply-To: <4E77FAF6.90707@extendedsubset.com> from "Marsh Ray" at Sep 19, 11 09:31:18 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: asteingruebl@paypal-inc.com, 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
Reply-To: mrex@sap.com
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:19:06 -0000

Marsh Ray wrote:
> 
> I've not been told the details of Duong and Rizzo's attack and haven't 
> seen "the BEAST" in action yet, so I'm not sure if that would be 
> sufficient to fix CBC in TLS 1.0. I am slightly annoyed at these guys 
> for dribbling out the information one hint at a time like this.

The "ekoparty conference" is 21-23 Sep., and usually if you get a
paper accepted for a conference, you're not supposed to publish
before the conference...


> 
> Last I checked, the TLS RFC stated explicitly that the protocol defended 
> explicitly against man-in-the-middle attacks. It did not say it defended 
> against "blockwise-adaptive chosen-plaintext" attacks.

It does defend against man-in-the-middle attacks.


> 
> But why split hairs over it? It breaks a basic security properties of 
> the system even if the application designer has done everything 
> according to the recommendations in the spec.

Wrong.  I do not believe that it breaks any of the security properties.
It does break some flawed assumptions.

SSL was NEVER designed with a promise that you could multiplex
data from an evil attack with data from a victim over the very same
SSL connection and be secure against adaptive chose plaintext
attacks trying to recover data from the victim.

>From the SSL design it is quite clear that for CBC encryption, the
encryption key is static for a single connection (=reused for every
cipher block), so mupliplexing data from evil and victim like it
is done in SSL-VPNs or allegedly here by "BEAST" by subverting the
browser security model, that is a clear abuse of the SSL protocol
beyond it's design limitations.

You see it in every episode of Star Trek -- whenever the captain decides
to operate the engines significantly beyond the design limits, the engine
suffers significant damages.  That's not "ficition", it applies similarily
to NASA spacecraft, to aircrafts, vehicles on the road and other products
of technical design.


>
> Since when did "trusted script only" in the application become a
> requirement for transport layer security?

Do NOT run trusted and untrusted data over the very same SSL connection,
because there are no properties in the SSL design to avoid this impairing
the resulting confidentiality.  SSL is no panacea or silver bullet
(never was) and using a technology beyond its design limits is
always a bad idea.


> 
> > Potential server-side mitigation of the problem:
> >
> >    - disable HTTP request pipelining (aka Connect: keep-alive)
> 
> Expensive.

Not for those braindead "secure checkout" or "secure payment" pages
in an otherwise completely unprotected online shop -- which includes
Paypal.


> 
> >    - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0
> >      is negotiated), and use RC4-128 instead.
> 
> Does TLS's use of RC4 still take the first bytes after initialization 
> with the key? Or does it discard the proper amount?

How significant is the RC4 initialization bias for a brief communication
with an SSL-secured checkout / payment ?

(The suggestion was meant to be a mitigation, not a solution)


-Martin