Re: [TLS] Rethink TLS 1.3

[Nico Williams <[e-mail]>]

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