Re: [TLS] RFC4492bis - Removing ECDH

Michael Clark <> Thu, 08 January 2015 02:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E2641A1AC3 for <>; Wed, 7 Jan 2015 18:21:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.467
X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KTtIv8Lam-iT for <>; Wed, 7 Jan 2015 18:21:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E4F31A1A7D for <>; Wed, 7 Jan 2015 18:21:56 -0800 (PST)
Received: from monty.local ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4) with ESMTP id t082hJBo010965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 8 Jan 2015 02:43:22 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=klaatu; t=1420685005; bh=3SGVGmuU6OvO6hGVUbBixPP4y1gpLFVd9Jcvn/mVv/c=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ioiYloSwfYGGyijuCld7wj1EJHoYo24Ww62fvAaiZNKUkDYRV40cbEgJmtGcjaqiB EMu678/yNwiCePWnwlIIXibHdWBzSFwcJ7eBgcRjSdiDWinIKJYif6byF1q5DZSu3u 9Bv1YfmLNirwlSQv/1AkuROkoRHT4ByNYvBiBWDM=
Message-ID: <>
Date: Thu, 08 Jan 2015 10:21:42 +0800
From: Michael Clark <>
Organization: Metaparadigm Pte Ltd
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Yoav Nir <>, " (" <>
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------030905070003070900010104"
X-Virus-Scanned: clamav-milter 0.98.4 at
X-Virus-Status: Clean
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 02:21:58 -0000


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

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



On 7/1/15 10:23 pm, Yoav Nir wrote:
> Hi.
> I realize this was sent right in the middle of the holiday season, so
> I’ll give it another try.
> Please have a look at the pull request and post comments to the list
> about whether you’re fine with removing ECDH.
> Thanks
> Yoav
>> On Dec 16, 2014, at 12:29 AM, Yoav Nir <
>> <>> wrote:
>> Hi.
>> I’ve created pulll request #2 for removing references to ECDH (static
>> elliptic curve key) key exchange and ciphersuites.
>> Nikos suggested it
>> here:
>> Yes, there are other suggestions there, but I’d like to take them one
>> by one.
>> Let me know what you think
>> Yoav