Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

Yaron Sheffer <> Sat, 21 September 2013 22:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2994A11E81A3 for <>; Sat, 21 Sep 2013 15:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.415
X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j0jrkX76YquT for <>; Sat, 21 Sep 2013 15:02:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::230]) by (Postfix) with ESMTP id 607F211E81A2 for <>; Sat, 21 Sep 2013 15:02:26 -0700 (PDT)
Received: by with SMTP id n12so1747155wgh.3 for <>; Sat, 21 Sep 2013 15:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IkiS/cWXTRt+FtLvYJ48LxjZhyOgSP+oP7LeQ0GnYxY=; b=zs/7aka9ehgQyL4OAkpbfuOC5yPN5LpkqQZtSx49musbvgj+dRYygzTkB4W+xi6yU2 YKiXjxiDMuu+ohFfaTRmeK5/upY4bosyAIgZ4HX/0zAScXF5PN3TPxCPk2MK3ufbIdLd 1yORgKCToRrqlIkx/HXuJVnAC39sjTgCuDgikzrL9biNX/2OhVpDikkTr8aWSsSk5Gd4 IVgXTQ24RUivOIhahTjeIS1c8P6avjFfUhhmxzFNXuMNuIaHk8UsawPEIl/GJyc8rEoc 3gdCTNZWetiu0yPqS+ly9uzm1qHOnVlFYJKBVpZ58WvVIWZbIqepbXO26EHDhzTpxqv/ Dduw==
X-Received: by with SMTP id hm7mr7687246wib.31.1379800945427; Sat, 21 Sep 2013 15:02:25 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id fz8sm14391404wic.0.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 15:02:25 -0700 (PDT)
Message-ID: <>
Date: Sun, 22 Sep 2013 01:02:23 +0300
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Peter Gutmann <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-Mailman-Version: 2.1.12
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: Sat, 21 Sep 2013 22:02:27 -0000

Hi Peter,

Thanks for the clarification. Two questions:

- Does any of this brittleness still apply when talking about ECDH (as 
opposed to ECDSA), with fixed parameters?

- Further supporting the brittleness argument... We recently specified 
recipient tests in IKEv2, that apply (and are actually 
security-critical) when either side reuses its DH private key [1]. The 
recipient needs to test that the received point is actually on the 
relevant curve. Are these mandated for ECDHE in TLS? I would have 
expected to see this requirement in [2] (reuse of DH keys is allowed in 
this RFC), but it ain't.



On 09/21/2013 11:42 AM, Peter Gutmann wrote:
> Yaron Sheffer <> writes:
>> I think we've been through all these arguments (on both sides of the issue)
>> over the last week, with the exception of "ECC brittleness". Can you please
>> clarify what you mean by that?
> So with RSA-authenticated DH all you need to do is use a constant-time modexp
> on the server when you sign and pre-encode the PKCS #1 expected result and use
> a constant-time memcmp() on the client when you verify and you're OK.  If you
> did that ten years ago then you're safe against pretty much everything that's
> come along since then.
> With ECDLP-based algorithms in contrast there's a whole range of issues you
> need to take into account, the worst of which is the distressing propensity of
> the DLP algorithms to leak the private key if you get even the tiniest detail
> wrong.  Not only do you have to get all of these finicky details exactly
> right, but every now and then someone points out a new issue that you then
> need to retroactively patch into your existing code base.  For example if you
> used the recommended (until not too long ago) way to generate your k for
> (EC)DSA then you'd leak a tiny bit of your private key on each signature
> (again, that nasty propensity of DLP algorithms to leak the private key).
> That's what I meant by ECC, and DLP in general, brittleness.
> Peter.
> _______________________________________________
> TLS mailing list