Re: [TLS] MITM Attacks on Client Authentication after Resumption

Watson Ladd <> Tue, 04 March 2014 03:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 656301A0320 for <>; Mon, 3 Mar 2014 19:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WBdI-aUiVGUF for <>; Mon, 3 Mar 2014 19:53:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::22e]) by (Postfix) with ESMTP id 713031A031C for <>; Mon, 3 Mar 2014 19:53:08 -0800 (PST)
Received: by with SMTP id v1so4465291yhn.33 for <>; Mon, 03 Mar 2014 19:53:05 -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=cEr5IHBHSd1+HZ4VLk/NW1lS2CL8taGO7uHn9xoGVH0=; b=GYQ8G8gvUgtI/iblTZpZbAh6h9H7Bnxldnhfy1692nOuHKhG2e1dFJGx/7JdYkzgno 3pwHp2HE7n2/AfkFCFWEV4hcnKtTioLqjO1YTwzf+Zyyo1F9Uae9Hs6VAZ/qH0K73Xrw f4xL6CpdiJRfAI1RkrX6dkxFrB0kAEQn4GEv+r4I8uPNsweMHFiIYc8ti1W77JFbxByz RWjwuolcNmH4S8P278Aay6Oo16ra2v7Wy7vyDflUy1xTwOKXrv9tylsTDnPXmSg+fZN1 EsI96fhtmCnfXnzp6j/Qc3ACFzb92AaYrloDpDpkLWj14UzK4aOC7bAa1btoeZJrrfG+ zRbw==
MIME-Version: 1.0
X-Received: by with SMTP id s71mr25129165yhj.45.1393905185178; Mon, 03 Mar 2014 19:53:05 -0800 (PST)
Received: by with HTTP; Mon, 3 Mar 2014 19:53:05 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 3 Mar 2014 19:53:05 -0800
Message-ID: <>
From: Watson Ladd <>
To: "Salz, Rich" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption
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: Tue, 04 Mar 2014 03:53:10 -0000

On Mon, Mar 3, 2014 at 3:32 PM, Salz, Rich <> wrote:
>> both of which were previously noticed in 2009 with the Rex/Ray attack.
> Hmm…  Four-plus years is a pretty darn good record, I’d say.

Protocols are not houses. They do not get mildew under the eves. Ants
and termites do not eat the foundation. Unless you are an extreme
intuitionist, TLS was as broken in 2009 as it was today. The pattern
of decision making by this WG is clear: mistakes are noticed, and the
fix doesn't actually cut to the core of the issue. This needs to end.
I'll submit a TLS 2 draft that will be formally verified, easy to
implement (modulo X509), and provide the secure channel semantics that
TLS still doesn't. The big nonsecurity payoff: very few round trips.
(1 if lucky, 2 if not)

>> why users should continue to trust TLS with confidential information.
> At the risk of being flip or snarky, because it’s the only thing we have.
> Therefore everyone uses it and therefore there are lots more “interesting”
> places for an adversary to attack.  As the old joke goes, I don’t have to
> outrun the bear, I just have to outrun you.

I'm not sure if that's comforting or alarming. As the old saying goes,
if you don't know who the sucker is, it's you. That's why I never play
poker thanks to application of Zorn's lemma. (Well, induction)

> At one point, the most common way banks transferred money amongst themselves
> was PGP signed data over FTP. I don’t know if it’s still true. The US
> Federal Reserve requires TLS over direct leased lines for banks doing
> transactions more than $10Million.

There's your answer: the Fed will not trust TLS with amounts over $10
million. Anyone here about to retire? My suggestion: call your broker
and never use their website ever again. Because if the Fed gets robbed
of $10 million they can print more.

>> Username password and cookies continue to be widely used in part because
>> client authentication in TLS has not had a good run.
> You mean because client certs are not widely deployed, right?  Perhaps some
> name/pbkdf2 is better?

The idea was that the browser would make certs and use them
transparently: this was the idea behind Channel ID. But that got
broken in this latest attack, unless you used ECDHE only.

Password based derivations don't solve the phishing problem, unless
you do something somewhat clever. (mix with hostname, then derive?)
But thanks to backwards compat, a phisher can always get the password.

Watson Ladd

>                 /r$
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA

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