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

Martin Rex <mrex@sap.com> Thu, 29 September 2011 13:48 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 A8D5221F8C37 for <tls@ietfa.amsl.com>; Thu, 29 Sep 2011 06:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.065
X-Spam-Level:
X-Spam-Status: No, score=-10.065 tagged_above=-999 required=5 tests=[AWL=0.184, 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 xgTTSuO15nLR for <tls@ietfa.amsl.com>; Thu, 29 Sep 2011 06:48:30 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED2721F8C1B for <tls@ietf.org>; Thu, 29 Sep 2011 06:48:29 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8TDpDhS015584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 15:51:18 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109291351.p8TDpD1C009420@fs4113.wdf.sap.corp>
To: mrex@sap.com
Date: Thu, 29 Sep 2011 15:51:13 +0200 (MEST)
In-Reply-To: <201109291344.p8TDiVcw009197@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 29, 11 03:44:31 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:48:34 -0000

Martin Rex wrote:
> 
> 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.

But this fragmentation should be done ONLY on protected application
data SSL records.  Fragmenting SSL records with handshake messages
(e.g. on TLS renegotiation) is likely to cause significant interop
problems in the installed base. (Yes, I'm aware that fragmenting
handshake records is allowed by the spec, but a significant
number of implementations will break if you do).

-Martin