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

Martin Rex <mrex@sap.com> Tue, 20 September 2011 21:50 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 96C5B11E80CC for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 14:50:57 -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 LKAatF7ovebw for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 14:50:56 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5893311E80BD for <tls@ietf.org>; Tue, 20 Sep 2011 14:50:56 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8KLrJ35018792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2011 23:53:19 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109202153.p8KLrIQj025096@fs4113.wdf.sap.corp>
To: mrex@sap.com
Date: Tue, 20 Sep 2011 23:53:18 +0200 (MEST)
In-Reply-To: <201109202131.p8KLVpd0024045@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 20, 11 11:31:51 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
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
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 21:50:57 -0000

Martin Rex wrote:
> 
> Nico Williams wrote:
> > 
> > On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> > > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <mrex@sap.com> wrote:
> > >> 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.
> > 
> > I wasn't there.  I don't know what it was designed for.  But here's
> > the thing: why shouldn't the designers have assumed that some of the
> > data sent over SSL might be untrusted?  On what grounds would it have
> > been OK to say "no untrusted data, please"?  And where was this
> > restriction documented?
> 
> It is a design limit that should be obvious to the conscious reader
> with background knowledge about cryptography.
> 
> 
> > 
> > But let's grant that restriction.  That would have meant that we
> > should never have allowed IMAP over SSL, for example, and taking the
> > argument to extremes, we should never have allowed HTTP POST over SSL
> > either.
> > 
> > This is really Marsh's point, I think, and I agree with it.
> 
> No, you're entirely confusing things.
> 
> 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.
> 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.

What I forgot: if the attacker knows the IV ahead of time (the IV that will
be used to CBC-encrypt the attackers chosen plaintext) or if the attacker can
force the IV value that will be used, then the guessing will become
extremely effective for low-entropy unknowns (provided that the attacker
knows the IV that was used for the unknown, but for CBC that is well known
whenever that IV is either explicit or when CBC is used and the unknown
io in a later block.


-Martin