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

Nico Williams <> Tue, 20 September 2011 23:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE85421F8CAE for <>; Tue, 20 Sep 2011 16:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TvtqJP1Ar+qp for <>; Tue, 20 Sep 2011 16:31:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BC3DB21F8CA9 for <>; Tue, 20 Sep 2011 16:30:50 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id B48B91F0087 for <>; Tue, 20 Sep 2011 16:33:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s=; b=LXmMsQYxGcfiVhX7jMWlFVDgN9kj8wSDA4/qfQfOV86W fRyaB7z3PR1rjVFp0/z6Khh49TM4WVhknA0KS+GmQpnvAKfLLCtGTaYI5RA+CX9X Osoh4ChbTtxipiytrsoHRwZ3sFzFK2qxZohEno6abcZMFQYca2nW8I8kTeHzkEM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s=; bh=5XG3wDD8t1WMIvSF1KqxjPY/aLo=; b=ZQmgmq2a1h8 pAwCLlaTcD5tOufN+AgOAHFO2foPFk050YS2ZyN/MTc7c3BekxSnJOSPz1yHDPF3 UX1+hyUXp9PqZ92GAkbWOnEnJZjnPEmdMqAQrLqVe6R2+CYOEc995TePpmwu8yMx i4kzevITZ+CFGQSJTxAful0RFHLzcAr4=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 954CE1F0081 for <>; Tue, 20 Sep 2011 16:33:17 -0700 (PDT)
Received: by pzk37 with SMTP id 37so548992pzk.9 for <>; Tue, 20 Sep 2011 16:33:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id a4mr362856pbo.64.1316561597117; Tue, 20 Sep 2011 16:33:17 -0700 (PDT)
Received: by with HTTP; Tue, 20 Sep 2011 16:33:17 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 20 Sep 2011 18:33:17 -0500
Message-ID: <>
From: Nico Williams <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Sep 2011 23:31:02 -0000

On Tue, Sep 20, 2011 at 4:31 PM, Martin Rex <> wrote:
> Nico Williams wrote:
>> On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker <> wrote:
>> > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <> 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.

It's been roughly two decades, and only now did this get noticed.  And
there are many experts who've worked on TLS and apps that use it.

Undocumented design limitations are not obvious, even if in retrospect
they should have been.

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

I said nothing about sharing of keys across connections.  I did not
even imply it.

> But when you start multiplexing adaptively chosen plaintext from
> an attacker with data from a victim, then you're creating an oracle.

Multiplexing?  Just mixing will do.  IMAP lets you... read emails from
untrusted sources (e.g., spam), as well as ones from trusted sources.
Oops.  This is silly.