IETF Logo Mail Archive

Re: [TLS] Rethink TLS 1.3

mrex@sap.com (Martin Rex) Mon, 24 November 2014 16:56 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC301A870D for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 08:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MZpYqBiU8PF for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 08:56:03 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEB21A7113 for <tls@ietf.org>; Mon, 24 Nov 2014 08:56:03 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 4B6D13A157; Mon, 24 Nov 2014 17:56:01 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 169DC41266; Mon, 24 Nov 2014 17:56:01 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 0E7A71B004; Mon, 24 Nov 2014 17:56:01 +0100 (CET)
In-Reply-To: <20141124105948.GH3200@localhost>
To: Nico Williams <nico@cryptonector.com>
Date: Mon, 24 Nov 2014 17:56:01 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20141124165601.0E7A71B004@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DZ-Q1BMged_7Rj9YOvcMDKAwTpg
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Rethink TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 24 Nov 2014 16:56:08 -0000

Nico Williams wrote:
>
> Henrick Hellström wrote:
>
>> Yes, but the point I am trying to make, is that if the implied goal
>> is to make TLS resilient even against BEAST/CRIME style attacks, the
>> threat model should be defined accordingly. It makes little sense to
>> ask for cryptographic review of the protocol, if it is inherently
>> unclear exactly what kind of threats the protocol is designed to
>> withstand.
> 
> BEAST/CRIME are dramatic demonstrations of the capabilities of attackers
> in the Internet threat model.


Nope.  BEAST, CRIME and Poodle are pretty boring demonstrations of the
ridiculous insecurity of WebBrowsers in their default configuration.

As I've previously mentioned, TLSv1.2 has an explicit product warning
label against such Browser fallacies, and explicitly rules out BEAST,
CRIME and Poodle from the attack model against which TLSv1.2 and
all prior TLS and SSL protocol versions provide protection.


The vulnerability of Web Browsers that attacks like BEAST, CRIME and Poodle
exploit is called "Cross-Site-Request-Forgery" (CSRF) vulnerability, e.g.:

   https://www.isecpartners.com/media/11961/csrf_paper.pdf

and as long as a Browser keeps providing authentication facilities
for requests supplied by attackers, the vulnerability is wide open,
independent of the TLS protocol version that is used (SSLv3, TLSv1.0,
TLSv1.1, TLSv1.2 or TLSv1.3).  Often, browsers will voluntarily supply
attackers access to CSRF for non-disclosing authentication schemes,
including TLS client certificate authentication.  So while current
disclosing authentication schemes make the problems worse, replacing
disclosing authentation schemes would only make boring demonstrations
like BEAST and Poodle less likely, but would not address and fix the
real problem (CSRF) at all.

For many programmatic clients and servers, attacks like BEAST and Poodle
are completely irrelevant, because the vast majority of these will neither
execute attacker-supplied active content, nor will they provide
Cross-Site-Request-Forgery facilities to attackers for free.


If there is anything wrong, then it is the current (lack of)
"Web Security Model" as it exists in common Web Browsers and as
it exists on a growing number of Web Servers.


-Martin

v2.23.0 | Report a Bug | By Email