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

Martin Rex <mrex@sap.com> Tue, 20 September 2011 22:56 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 17EF421F869E for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 15:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.038
X-Spam-Level:
X-Spam-Status: No, score=-11.038 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, GB_I_LETTER=-2, 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 Jf17zU5vouND for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 15:56:32 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA0221F86FF for <tls@ietf.org>; Tue, 20 Sep 2011 15:56:31 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8KMwr8M022953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 00:58:53 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109202258.p8KMwqdU029069@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Wed, 21 Sep 2011 00:58:52 +0200
In-Reply-To: <4E790A09.7020007@extendedsubset.com> from "Marsh Ray" at Sep 20, 11 04:47:53 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 22:56:33 -0000

Marsh Ray wrote:
> 
> Yeah CBC sucks, especially with predictable IVs.
> 
> It's a weakness.

It is a well known design characteristic of CBC-Mode.

It only becomes a weakness when CBC-Mode is used inappropriately,
like when the same key is used to protect data that ought to be
seperate.  Or when it is used in a fashion that gives attackers
an easy "adaptive chosen plaintext attack capability" for free.
(Applied Cryptography 2nd Ed., page 6 (4.)  -- such as a Web-Browser
that not only runs arbitrary active content as a courtesy to the
attacker, but also lets this malicious code re-use an established
SSL connection through which supposedly confidential data was
transmitted to mount an adaptive chosen plaintext attack.

On my sorecard, that is a Browser shooting itself in the foot.

> 
> > It was not a design requirement at that time, so that property does
> > not exist in the original SSLv3 (and TLS) design.  When cipher suites
> > with stream ciphers are not affected, then this is a lucky coincidence,
> > not a result of a conscious design (based on a requirement).
> 
> Well where does that reasoning end?
> 
> If a defect were found in TLS which could be exploited using long 
> strings of the letter 'A', would you say that the protocol was never 
> "designed to resist long strings of the letter 'A' attacks"?

That would be a weakness in the chosen cipher and the particular
operating mode that was used for the particular affected cipher suite.

Of course, the TLS protocol will inherit any weaknesses from underlying
crypto protocols.


The TLS renegotiation problem was not a protocol defect of TLS,
it was a flawed assumption of consumers of TLS about a security
property that never existed.  And obviously, noone who relied on
TLS renegotiation to be secure ever cared to look at the protocol
specification and check whether it really provided such a
security property.  Anyone who had _seriously_ looked at TLS
would have realized that no secure renegotiation property existed
in the original SSLv3 specification.


> 
> This protocol is something called "IETF Transport Layer Security". It's 
> not "Security for Data That M. Rex Feels Web Browsers Should Be Able to 
> Transport Securely". :-)

I know that it is called "IETF Transport Layer Security".
But lots of folks seem to confuse TLS with "magic pixie dust" or "snake oil",
a panacea that cures everything, known and unknown -- and completely
fail to recognize that _every_ design has limits and ignoring any
such limits will regularly have dire consequences.


If random pads are reused and that results in recovery of both messages
that were protected with that random pad through cryptoanalysis of
the XORed plaintexts, then this is not a "totally unexpected weakness of
the random pad encryption scheme", but instead a known design limit
and a complete failure of the users who goofed the management of
the cryptographic keys (the random pad).

I haven't yet seen a detailed description of the BEAST attack, but
what has been leaked so far (and that TLSv1.1 is allegedly not
susceptible to this particular attack) suggests that they're
exploiting a definite design flaw in the web browser that exhibits an
obvious and serious negligence in the management of TLS connection states
therefore providing a free "chosen adaptive plaintext attack" facility
as a courtesy to the attacker besides the courtesy to run arbitrary
attacker-supplied active content.


-Martin