Re: [TLS] Rethink TLS 1.3

mrex@sap.com (Martin Rex) Mon, 24 November 2014 17:13 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 D69B21A8741 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 09:13:31 -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 UhZgpM2r0GqC for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 09:13:29 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1161A875D for <tls@ietf.org>; Mon, 24 Nov 2014 09:13:21 -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 smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 628593A1B0; Mon, 24 Nov 2014 18:13:20 +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 4EEBE41223; Mon, 24 Nov 2014 18:13:20 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 45D2D1B004; Mon, 24 Nov 2014 18:13:20 +0100 (CET)
In-Reply-To: <20141124170257.GJ3200@localhost>
To: Nico Williams <nico@cryptonector.com>
Date: Mon, 24 Nov 2014 18:13:20 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141124171320.45D2D1B004@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/448Ld3Pp3QviFotaFdtei9JZW7c
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 17:13:32 -0000

Nico Williams wrote:
>
> Martin Rex wrote:
>>
>> Nope.  BEAST, CRIME and Poodle are pretty boring demonstrations of the
>> ridiculous insecurity of WebBrowsers in their default configuration.
> 
> Yes, they were that too.  And by then we knew well about adaptive
> plaintext attacks.  Still, they also were demonstrations that the
> network has to be assumed to be under control of the adversary, and IMO
> they were dramatic at that.  If anyone still doubted the adversary's
> control of the network before BEAST, no one does now.


5 years ago there was an exhausting discussion in this WG about how to
fix the TLS renegotiation issue.  The problem had been considered so huge,
that a secret group (Project Mogul) had been setup to design (and have
patches shipped) before the issue was publicly described.

BEAST and Poodle require *MORE* control over the endpoint as a prerequisite
for the attack than what a successful TLS renegotiation attack will provide.

Please stop claiming that providing so much control to an attacker
as something that is (or should be) normal, rather than considering
providing so much control to attackers as what it really is:
a huge and gaping vulnerability in Web-Browsers and in the
(lack of a) Web Security Model.


-Martin