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

Phillip Hallam-Baker <> Tue, 20 September 2011 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADDE421F8B01 for <>; Tue, 20 Sep 2011 13:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.466
X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KbWT1xviN2eo for <>; Tue, 20 Sep 2011 13:01:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 082BD21F8AFA for <>; Tue, 20 Sep 2011 13:01:56 -0700 (PDT)
Received: by gyd12 with SMTP id 12so790507gyd.31 for <>; Tue, 20 Sep 2011 13:04:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RspFcP6Jcs4M6tfGBmvt6H51eDugRoJSU6AiIvhDtSw=; b=ip/OxuE2vVFz+pGaE7jkHvlsU4ciGstQ5Veoxohu83yu+pGAKi1Xk3Q9XBBsUtPQ47 5FRfjtQuqxnRIdeY37prI4hdTNvt2iW5qQsEZgc2VVIGpqZRfbUHC6gDeh0L6YOUWH9+ eB+yjL1dtl0Xfc4lSkigQH6drFX/oc9WmfZm0=
MIME-Version: 1.0
Received: by with SMTP id v6mr1174083anq.140.1316549063562; Tue, 20 Sep 2011 13:04:23 -0700 (PDT)
Received: by with HTTP; Tue, 20 Sep 2011 13:04:23 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 20 Sep 2011 16:04:23 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
Content-Type: multipart/alternative; boundary=001636ed746443565804ad64f764
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 20:01:57 -0000

On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <> wrote:

> Marsh Ray wrote:
> > But why split hairs over it? It breaks a basic security properties of
> > the system even if the application designer has done everything
> > according to the recommendations in the spec.
> Wrong.  I do not believe that it breaks any of the security properties.
> It does break some flawed assumptions.
> 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.

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

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

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