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

Martin Rex <mrex@sap.com> Thu, 29 September 2011 13:41 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 DF1E021F84AB for <tls@ietfa.amsl.com>; Thu, 29 Sep 2011 06:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.064
X-Spam-Level:
X-Spam-Status: No, score=-10.064 tagged_above=-999 required=5 tests=[AWL=0.185, 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 SnOXh0j6QhQe for <tls@ietfa.amsl.com>; Thu, 29 Sep 2011 06:41:45 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 20C9421F8D3C for <tls@ietf.org>; Thu, 29 Sep 2011 06:41:44 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8TDiVdv012601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 15:44:31 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109291344.p8TDiVcw009197@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Thu, 29 Sep 2011 15:44:31 +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: Thu, 29 Sep 2011 13:41:50 -0000

Marsh Ray wrote:
> 
> >    - 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?
> 
> I believe there was a mitigation put in place by OpenSSL: sending an 
> empty (just padding) message before each app data message. The document 
> at eprint.iacr.org/2006/136 suggests that this could be a server-side 
> only change. I don't see how that would work since the session cookie 
> recovery attack is clearly happening on the client->server channel.
> 
> I read somewhere that this mitigation was off by default in OpenSSL 
> because it some software (an old MSIE IIRC).

Why using a EMPTY (just padding) SSL record?  That looks like an
obvious untested border case.

How about using an initial SSL record with one byte of real data
for SSLv3 and TLSv1.0 SSL with CBC cipher suites?

Since the (H)MAC is using a secret MAC key and directly following the
data (the CBC padding is at the end), there will be significant
unknown distortion in the resulting plaintext to make the BEAST
attack impractical, I assume.  And it could be done immediately
on the browser side, without having to wait for the Servers
to implement TLSv1.1.


-Martin