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

Martin Rex <mrex@sap.com> Tue, 20 September 2011 14:43 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 C74D221F8C8A for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 07:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.037
X-Spam-Level:
X-Spam-Status: No, score=-10.037 tagged_above=-999 required=5 tests=[AWL=0.212, 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 vNyFXJJ0S5Xv for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 07:43:40 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 593DB21F8BEB for <tls@ietf.org>; Tue, 20 Sep 2011 07:43:36 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8KEjvpM022396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2011 16:45:57 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109201445.p8KEju3B029762@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Tue, 20 Sep 2011 16:45:56 +0200 (MEST)
In-Reply-To: <CABcZeBM5CK2Tdr3v5662DfKtzPvRHntPRQsAwzz3JaeNtHBrKw@mail.gmail.com> from "Eric Rescorla" at Sep 19, 11 08:49:27 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 14:43:40 -0000

Eric Rescorla wrote:
> 
> On Mon, Sep 19, 2011 at 7:31 PM, Marsh Ray <marsh@extendedsubset.com> wrote:
> > Does anyone believe there would be support for a TLS 1.0 Hello extension
> > that could compatibly negotiate the use of empty messages in each direction
> > as a mitigation for this attack?
> 
> The difference between TLS 1.0 and TLS 1.1 is so slight that if TLS
> 1.1 is indeed immune it would probably be easier to just have servers
> upgrade to 1.1.


Using the TLSv1.1 explicit random IVs for TLS cipher suites with
block ciphers in CBC-mode would be my preferred solution -- provided
that a significant majority believes this to be a sufficient mitigation.
(Personally, I think that it is not a clean solution, but may be OK
 as a mitigation that makes this attack sufficiently "expensive").


I don't see why adding and enabling TLSv1.1 on Servers should cause
interop problems, but I'm completely lacking experience in that area
to make any assessments. 

A client that announces TLSv1.1 (and no application level reconnect
fallback) is much more likely to run into interop problems, similar
to a client that includes a TLS extension in ClientHello.  Newer
Browsers (those that are affected by this Man-in-the-Browser attack)
usually have a reconnect fallback capability and should be able
to cope with this.


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.
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.


-Martin