Re: [TLS] Rethink TLS 1.3

Watson Ladd <> Mon, 24 November 2014 17:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8D591A876D for <>; Mon, 24 Nov 2014 09:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id knYNkNG6DoU3 for <>; Mon, 24 Nov 2014 09:35:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 706871A8767 for <>; Mon, 24 Nov 2014 09:35:21 -0800 (PST)
Received: by with SMTP id f10so4473528yha.4 for <>; Mon, 24 Nov 2014 09:35:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=22gUO99Gj/A8KQEnwMroP5vLC/TLDkMB1aLiFJ2V8Gc=; b=TzIQggXUmciJMW9wvxjRatBYFi/axf3qk78xv7wMCyHe0UMTn/3MwIgSMHA5wADPbR t74pV043AUufCX4FtVyWNVBSZiuso0DugbRcxXC3+5bq2YiuOa8h53gWrRrODnsMgXj6 WFt+keRG1GLXYi3kkt66BWvDsnHK62sLclYQq2FB6a6Fu0tOy9c+IZuz8eA9L4JRCrnV PzExYYRwDvbQD4CLIwqGvhRV5QGHaULq0uMC3OGOKp++utB9W/YOPKGwoAAHyEt2B2yQ 4sKX3bxaf8TlfJL1piqcY9unnUCIz7NEK3n1xiRtCZFK3kyLCyjxSXExh4WVHUvbrDFq FTOQ==
MIME-Version: 1.0
X-Received: by with SMTP id k45mr19164967yha.163.1416850520514; Mon, 24 Nov 2014 09:35:20 -0800 (PST)
Received: by with HTTP; Mon, 24 Nov 2014 09:35:20 -0800 (PST)
In-Reply-To: <>
References: <20141124105948.GH3200@localhost> <>
Date: Mon, 24 Nov 2014 09:35:20 -0800
Message-ID: <>
From: Watson Ladd <>
To: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [TLS] Rethink TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Nov 2014 17:35:24 -0000

On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex <> wrote:
> 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.

So it's possible to get my Paypal login cookie if I browse to a
malicious site on a fully patched browser? Because that's what BEAST
enabled. Are you saying it's fine that SSL v3.0 leaks one byte per
connection? Because that's POODLE. All of this was known in 2004, and
not fixed in TLS 1.2: no action was taken on publicising the
vulnerabilities, and in the case of some of the CBC mode issues,
vulnerable options were left in. If the web browser is inherently
insecure because it runs javascript, where's the exploit?

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

If TLS provided a secure channel as defined in, then the browser wouldn't have a
problem. Workarounds around the lack of an easily provided property
are never a good idea, unless you know exactly what the problems are.
Why are you so dead set against making TLS useful for browsers?
Providing the right properties isn't that hard: the correct thing to
do looks very similar to the wrong thing, except it's correct.

What are the exact security claims of SSLv3.0? Or TLSv1.0?

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

Just because you don't like the Web Security Model doesn't mean it
doesn't exist. In fact, if you read the link you posted you would see
very simple solutions to the CSRF problem, that work unless the
"secure channel" isn't.  By contrast, a web application that uses
cookies for authentication, and is reachable over TLS 1.0 with an
unpatched browser or RC4, is completely vulnerable, and can do nothing
to solve the problem.

Don't believe there is a difference? Go extract an authentication
cookie from a CSRF vulnerable endpoint. You can easily hit the
endpoint and trigger actions, but you won't get the cookie, and so
can't attack other endpoints. CSRF is a confused-deputy issue: a
capability based model would solve it. But we can't end CSRF without
making it impossible to do things like isolate user accounts from
content as protection against XSS, or federate authentication.

This isn't even about browsers: TLS based VPN solutions also have to
worry about BEAST. Something as simple as programmatic
username-password authentication can be broken if the client
automatically retries on failure. POODLE leaks one byte after a
certain number of connections are broken: are you sure your code never
retries on failure?

We could fix all of this by providing an actually secure protocol.
What's the disadvantage?

Watson Ladd

> 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
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin