Re: [TLS] RFC4492bis - Removing ECDH

Yoav Nir <> Thu, 08 January 2015 04:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 48D3C1A8843 for <>; Wed, 7 Jan 2015 20:42:36 -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 iKs41VKYl4bc for <>; Wed, 7 Jan 2015 20:42:34 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 118FD1A1A9D for <>; Wed, 7 Jan 2015 20:42:34 -0800 (PST)
Received: by with SMTP id w62so416689wes.13 for <>; Wed, 07 Jan 2015 20:42:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vxYeWbUVc8SRdsugsi4l1n0vpZoPTA36x7B7uWOeV9c=; b=ELO6IoUboxQw7iMKwc5vSHpgx+UGW4XOddmO0zN5intMVG1SH3RfNVAFHpNETxh4Mk FkB7vcHQ/o+1oTKO9vNAq8Wu4vuFo/2IxaDkuVTCDjGTY5ANvbIZUmO5wQg7QIJohed9 /oHviR7M5MRYnWMSOPdnKYCgrMMytero0umlmQeHnB93zwKVl0fM7lwROfx1LE3Izkbb q0TrudFiBIldt2FNpc0nGhvQLRPYhW0JXfMY2kc1FF2Vp0of+fqF0yflFG5BUEaHgYNL Ak+BP+erLiBRJF4j1Ix9e1jRzrnnbe6DqHRFOWSDppPoJ9NRMrgiTeJd6Tm2de7wfx3+ gIYQ==
X-Received: by with SMTP id 16mr14758160wjx.108.1420692152790; Wed, 07 Jan 2015 20:42:32 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 18sm4487891wjr.46.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 20:42:32 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Thu, 08 Jan 2015 06:42:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Michael Clark <>
X-Mailer: Apple Mail (2.1993)
Cc: " (" <>
Subject: Re: [TLS] RFC4492bis - Removing ECDH
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: Thu, 08 Jan 2015 04:42:36 -0000

Hi, Michael

> On Jan 8, 2015, at 4:21 AM, Michael Clark <> wrote:
> Hi,
> After spending 14 years in Asia I get mixed up with holidays and started calling them Solstice holidays and Lunar holidays (Feb 19th this year). I'm hoping I can have a break in the Lunar New Year. My family in New Zealand celebrated Solstice holidays without us... as we still trying to /Escape from Singapore/ (reminds me of Snake Plissken)... we'll make it out. We still have Internet access here. (*1,*2) ;-).
> Yes. You might want more consensus, however as a data point, I am in support of ephemeral key negotiation mechanisms that /in theory/ preserve forward secrecy and for removing those that leave administrators hamstrung (and aren't implemented). i.e. fine with removing ECDH. There appears to be an emerging consensus from server administrators and the certificates issued from all major vendors have "Parameters: None". In the case they were used in       practice, they would make attack mitigation depend on third parties.
> My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH requires the CA to embed static named or explicit points in certificates. The practice is that implementations let server administrators choose and /sign/ *somewhat* ephemeral parameters e.g. secp256r1,  secp384r1 works widely, but secp521r1 failed in my tests with Win8.1 IE11; this report matches my data point: (*3). I use the word /sign/ loosely until we have a proof that handshake messages can't be replaced in situ (*4). i.e. the client and server establish a chain of trust from their first Hellos to the pre-master secret establishment; which is possible with careful refinements to the protocol (constant salt in AD across all handshake messages). This of course then pushes an integrity problem down to another layer. i.e. DNSSEC (*5).

#4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video clips with crashing planes?

> It raises another question. Is DH_anon a misnomer? Should it be DHE_anon? Is it used anywhere in practice?

It is a misnomer. It is not used on the web, but it is used in some situations. For example, my company’s firewalls use it to establish the initial trust between a firewall and the management station. They will establish a TLS connection with DH_anon (should be DHE_anon, I guess), and then run certificate enrollment over that.