Re: [TLS] Rethink TLS 1.3

Nico Williams <nico@cryptonector.com> Mon, 24 November 2014 17:29 UTC

Return-Path: <nico@cryptonector.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 4145E1A6FFF for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 09:29:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 Jq-80DyLEBZ4 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 09:29:45 -0800 (PST)
Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 55BDB1A6FF2 for <tls@ietf.org>; Mon, 24 Nov 2014 09:29:45 -0800 (PST)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 37FFC1E071; Mon, 24 Nov 2014 09:29:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=em0o0EyE5g0eFX wQKV8zU92UbRg=; b=yNFAFIHoonXSm5lfxVZoj8ELkfjrQ0qpDfBJEKmi7NUpvm 8mxs9LnyU1nnHGmxWK9n1umGsP3V89WFMfLIh2S/c8xH8KXaN1k4prMHDnHV4CuC A7c/Yrcyma+yURYf+zoqhDfjSGFQ2s0MYT5ZiG2tbne34mKTeLH7klHKfAwN0=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id D9B3E1E05D; Mon, 24 Nov 2014 09:29:44 -0800 (PST)
Date: Mon, 24 Nov 2014 11:29:44 -0600
From: Nico Williams <nico@cryptonector.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20141124172942.GK3200@localhost>
References: <20141124170257.GJ3200@localhost> <20141124171320.45D2D1B004@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141124171320.45D2D1B004@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3O3I1Q3XZ-K0WE5zCaqaR4_6bCg
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
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:29:46 -0000

On Mon, Nov 24, 2014 at 06:13:20PM +0100, Martin Rex wrote:
> 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.

Renego, incidentally, was a feature of TLS that was originally not part
of the spec, but grew ad-hoc.  This is one of the ways in which we
failed SSL and its users: we didn't analyze the protocol as-used.

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

So what?

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

I'm claiming that we're not in a position in this WG to fix the web
security model to use something better than cookies and other bearer
tokens.  I wish we were, but we're clealy not.  There's proof of this in
the pudding.

There were several efforts in the last few years, in the WEBSEC and
HTTPauth WGs to do something about that, and those efforts failed.
HTTPbis is very active, but they are not doing something about this
either (unless that's changed recently; I don't follow HTTPbis closely).

Many things were tried, including some that were -IMO- pretty good
ideas, like origin-bound-cookies (which was good in large part because
it implied minimal or no real changes to HTTP stacks).

That means that TLS 1.3 simply MUST be resistant to various cookie
recovery attacks.  Those attacks have to be active attacks (therefore
foreseen by the Internet threat model) of the adaptive chosen plaintext
or similar varieties.  Fortunately we know how to beat them, therefore
we don't have to go fix the web security model *even though* we all
would like to also do that anyways.

BTW, I'd like to be wrong about this.  I'd like us to get so incensed
over web cookies that we get that part of the web security model fixed,
full stop!

Having attempted -and failed- to provide an alternative to web cookies
myself, I'm wondering how else we might fix them...  Dirk Balfanz's
latest proposal is OK with me, but I am so traumatized (in a way) by
BEAST that I'm inclined to accept just about any improvements as to web
cookies, especially ones where big players will do the work to get
started on deployment.

Nico
--