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

Yaron Sheffer <> Tue, 17 September 2013 19:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6825511E82C3 for <>; Tue, 17 Sep 2013 12:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.56
X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EsUnvIn627Zi for <>; Tue, 17 Sep 2013 12:21:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::229]) by (Postfix) with ESMTP id A407511E82B2 for <>; Tue, 17 Sep 2013 12:21:28 -0700 (PDT)
Received: by with SMTP id l18so4823725wgh.0 for <>; Tue, 17 Sep 2013 12:21:27 -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=g5osdhLM3YMx7XD/oAXh1nj6/8/PBY+5oT4Lf0fFoQc=; b=zSiWo1rU8hSFlZr7AmMiypYswPgyl0oerK3L5D2sU/JOkfJwEcoB+JHAVxCsWLCdZ5 7kDMfpkmQ54r6SBrQAquNYhXMqzqoH5MhElUWyPkd+ulywZtcJjyjU0JfxNr0rvSMP/n xYFH2jtrZZKPuxPN9cS225sYuLyp2UyZ6SteyXyEfxYtlBAkvei/arQIxL2jZgZ42Hhc awDhmWW8Zjpg1JbsAtpztD4stKmRekGXouNt3j1kJnkYQb2tl19e46oMOgJ31bmrJU0Y lcUUWHK9MfRNWPFntuLhu00mKKvqXR2f7j81uSCNTSVvC7K3IaBBqZnVjcL/e8mnyQKh Gv2g==
X-Received: by with SMTP id sp7mr3895774wic.2.1379445687803; Tue, 17 Sep 2013 12:21:27 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id z13sm6667198wib.0.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 12:21:27 -0700 (PDT)
Message-ID: <>
Date: Tue, 17 Sep 2013 22:21:20 +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
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: Tue, 17 Sep 2013 19:21:29 -0000

Hi Martin,

IMHO this is far from clear-cut.

There is some IPR mess surrounding ECC. But I know of vendors who are 
avoiding it by interpreting the IPR statement as referring to CAs 
(rather than endpoints), with the NSA license and RFC 6090 serving as 
fallback (NSA is your friend :-). As an example, Red Hat and Canonical 
are arguably in a similar position, but Canonical includes OpenSSL with 
ECC while RH disables it.

Our -00 draft proposed MODP DH, because it is simpler and more widely 
implemented. But I now prefer ECDH despite the drawbacks of ECC, because:

- Important implementations are broken, and will abort the connection 
when receiving >1024-bits DH.
- Modular DH cannot be negotiated, so there's no way for the server to 
know what the client supports and whether it'll break.


On 09/17/2013 04:14 PM, Martin Rex wrote:
> Yaron Sheffer wrote:
>> So yes, I agree. Here's from our work-in-progress -01 version:
>> As currently specified and implemented, elliptic curve groups are
>> preferable over modular DH groups: they are easier and safer to use
>> within TLS.
> Elliptic curve crypto is still fenced with non-expired patent claims,
> requires an implementation of elliptic curve algorithms and the
> relevant TLS extensions (something which is FAR from universally
> available) and elliptic curve technology is considerably more
> sensitive to side channel (=timing) attacks that DH, RSA & DSA.
> -Martin