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

Nico Williams <nico@cryptonector.com> Tue, 20 September 2011 21:02 UTC

Return-Path: <nico@cryptonector.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 41F3E21F85AA for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 14:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level:
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_32=0.6]
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 tYGAms7tGo7s for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 14:02:00 -0700 (PDT)
Received: from homiemail-a63.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id B96C421F888A for <tls@ietf.org>; Tue, 20 Sep 2011 14:01:59 -0700 (PDT)
Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 6097E2F4059 for <tls@ietf.org>; Tue, 20 Sep 2011 14:04:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=vXWB7ZrRChI/4xBGjwdbt 2dfgzJKRMOYXxsOuag1hwuLoLhfjh2DQnlFhOHXUy/iBN1/z8gvaqzanX4UYPZjv K+2EBmfXjbynealFDyAWCyj3sWHVN8egwsQTQJ2fiDqJ3cLroWjHqcUSKWpu9Xx7 8KBhxlKAIdDPJMXzHOU9mk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ycyBSfOggFeWKiAyWf3C Pvnwm9s=; b=tjVJw4vpzEK4alko77LhX1W65ZyJ5bh+Jo418ZxKA8pyx7AYFheL NevGrVWN31vgIU0osWSxXftKi0k+5HiqbdMu+jUZwNqlma/9+8Gr05QrEFkM/hMl Y3y3GYBAmAbiCre+7eHNrP7tK/19L+ItMSkHx3rOl6mE0tQq2+4Cdb8=
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 4401D2F4057 for <tls@ietf.org>; Tue, 20 Sep 2011 14:04:26 -0700 (PDT)
Received: by pzk37 with SMTP id 37so272983pzk.9 for <tls@ietf.org>; Tue, 20 Sep 2011 14:04:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.0.170 with SMTP id 10mr141346pbf.198.1316552665780; Tue, 20 Sep 2011 14:04:25 -0700 (PDT)
Received: by 10.68.60.4 with HTTP; Tue, 20 Sep 2011 14:04:25 -0700 (PDT)
In-Reply-To: <CAMm+Lwh47fs7FGRZ0mTFCMDhNZc8nfZ+2UEbKpLNEiYn6DXZpg@mail.gmail.com>
References: <4E77FAF6.90707@extendedsubset.com> <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp> <CAMm+Lwh47fs7FGRZ0mTFCMDhNZc8nfZ+2UEbKpLNEiYn6DXZpg@mail.gmail.com>
Date: Tue, 20 Sep 2011 16:04:25 -0500
Message-ID: <CAK3OfOiHddQxi_HGQ94w7tPCQ4Mcr1dRJOABBpcxd95RfNFF9A@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset=UTF-8
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
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:02:01 -0000

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?

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.

> SSL came before Javascript and even before cookies. So this is certainly
> outside the model.
> Adding AES in CBC mode probably came after the model had been changed
> though.

Yeah, sure, but I think it's fairer to say that the subject probably
didn't come up, not that SSL was not intended for this.

> If we want to avoid this type of attack we should probably change the
> encryption mode. I don't like stream ciphers in general, but SSL was
> designed round one and has been extensively verified when a stream cipher is
> used.
> From a design point of view, re-use of the same key to encrypt each block is
> bad news and turning a block cipher into a stream cipher is bad news. Anyone
> know why CBC is so popular vs PCBC?

Block ciphers in counter mode are as broken in the face of key&IV
reuse as any stream cipher, and for the same sorts of reasons.  This
is not a reason to not use counter modes.  It's a reason to use them
with care.

For example, in a situation like Kerberos' PDUs counter modes are
dangerous because there's no "connection" context for most of those
PDUs, thus no way to prevent key&IV reuse.  But for TLS, and even
DTLS, there's no such issue.

Nico
--