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

Yaron Sheffer <> Sun, 15 September 2013 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1EC111E81D7 for <>; Sun, 15 Sep 2013 14:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.442
X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rN-ukL7HCWgz for <>; Sun, 15 Sep 2013 14:16:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::236]) by (Postfix) with ESMTP id 90C4111E81D5 for <>; Sun, 15 Sep 2013 14:16:10 -0700 (PDT)
Received: by with SMTP id m15so2940996wgh.33 for <>; Sun, 15 Sep 2013 14:16:09 -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=8J6D9kiwB0GaIAP9GpY9NCY/srlXiYTzO/vIom9WfTI=; b=Xa+0EQac8YCDBU7Ijl7EF0REv0fteYUz+/NyJj/RkzjuKydRQXD8TRqpmNqqYqxJls JgEmntW5hCvFGZW4u+WNzaUe9gswSnDFQlpih6jXFLL37KS7+m6G1iRn445D+EI2exlJ zN+02xgDxB0yDXsPpj9cnGhl0Y6jfDwb0vZUStRgv9P0ZeljaNeqYbcGJi2Wn/eBZKi9 3pEWYKb3U/oRGBCQVH+O5dkKPlaOR+SK7LwOxA/JufmHUxUZ6bDFcDwyes9tfvRFz5iL xdN6Kqa8FMtbxJWjbQ2XWAwSgfOZBhA3FD9XeJn5FG02Bcizi9tyJ3sqoIQxOcDqQYg7 tQcQ==
X-Received: by with SMTP id gr8mr10732778wib.11.1379279769657; Sun, 15 Sep 2013 14:16:09 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id dx7sm18982341wib.8.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 14:16:09 -0700 (PDT)
Message-ID: <>
Date: Mon, 16 Sep 2013 00:16:07 +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: Yoav Nir <>
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: Sun, 15 Sep 2013 21:16:11 -0000

Hi Yoav,

ECDH groups are negotiated using RFC 4492 extensions, which surely makes 
them more usable today, and allows for crypto-agility in the future.

There are worries about the way the NIST curves were generated. AFAIU, 
most everybody uses P-256. Currently this is plain FUD, no-one can say 
whether and how you can backdoor ECDH if you control generation of the 
curves. But you can bet this research topic has suddenly become very 

If we assume that the adversary hoards millions of terabytes of network 
traffic for later decryption, perhaps in 10 years, then we need to worry 
about the strength of the curves we recommend today.

I guess for the time being we could recommend ECDHE with P-256, 
migrating later to a verifiably random curve like Brainpool.


On 09/15/2013 10:56 PM, Yoav Nir wrote:
> Hi, Yaron
> Why do we need to give up on PFS? There are ECDHE ciphersuites that are supported by nearly all browsers as well as well as OpenSSL (which means also Apache), IIS and others. Connect from any browser other than Opera to a Google server, and you'll be using a ECDHE-RSA ciphersuite.
> So why do we need to give up on PFS?
> Also, you are right that it depends on your threat model, but I think under most reasonable threat models, it's easier to steal a long-term private key (even if it's 2048-bit) than to calculate a discrete log in a 1024-bit group. Even harder to calculate a discrete log once for each session (it is ephemeral D-H), than to steal a single private key that is stored on a hard disk for at least a year.
> So no, I don't think we should give up of PFS.
> Yoav
> On Sep 15, 2013, at 10:11 PM, Yaron Sheffer <> wrote:
>> Hi,
>> I've been working with Ralph Holz on -01, and we would like the group's opinion before we publish.
>> Several people proposed that we recommend parameter lengths for RSA and for Diffie Hellman. RSA is easy enough, and we will recommend 2048 bits. The situation with DH is extremely messy, and if we're not careful, we might actually hurt security by recommending a reasonable parameter length!
>> Basic facts and assumptions:
>> - Brute force difficulty is similar for RSA and DH parameters of the same length.
>> - When using DHE, the TLS master key depends on the DH exchange only, and the certificate size doesn't matter.
>> - 1024 bit DH (or RSA) is still very common, but is too weak to recommend for the next few years.
>> We would like to recommend using 2048-bit DH by both client and server (maybe 1536 bits for performance, but for sure not 1024). But reading [1] and similar posts, this could have two undesirable consequences.
>> 1. Some older clients will break (abort the negotiation) if they offer DHE, the server accepts it but sends a DH value whose length they don't support (e.g. higher than 1024). You might end up with a non-TLS connection or a 404, rather than the client retrying with no DHE.
>> 2. New clients will follow our recommendation and offer DHE, but then will only receive 1024-bit DH parameters from (an older) server and will end up negotiating a weaker session than they would have negotiated if they'd avoided DHE, if the server happens to use 2048-bit RSA. (Yes, whether this is "weaker" depends on your threat model).
>> Problem #1 goes away if we say that the server only sends 2048-bit DH parameters to "new" clients (those that offer TLS 1.2), and assume these can all deal with DH of any length. Our draft recommends a TLS 1.2-only cipher suite anyway. And since new clients are still rare, this could work.
>> This partial solution is complicated by IE10, which (AFAIK) supports TLS 1.2, but has this support off by default, and does not support larger than 1024-bit DH.
>> Problem #2 is mitigated if we suggest that clients fall back to non-DHE if the server cert is long enough, specifically to TLS_RSA_WITH_AES_128_GCM_SHA256. That is, if the client doesn't like the returned DH parameters, it aborts the session and re-negotiates it instead of choosing the 1024-bit DH option.
>> This extra logic is ugly. But if we cannot recommend >1024 DH, we may be better off giving up on PFS for now. Long term, I believe that TLS should negotiate DH explicitly.
>> Your thoughts, opinions and even facts :-) are most welcome.
>>     Yaron
>> [1]
>> _______________________________________________
>> TLS mailing list