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

Yoav Nir <> Sun, 15 September 2013 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA6EB11E81B6 for <>; Sun, 15 Sep 2013 12:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.124
X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id co14lSEGOqD2 for <>; Sun, 15 Sep 2013 12:56:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D24FC11E81B4 for <>; Sun, 15 Sep 2013 12:56:32 -0700 (PDT)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r8FJuG8I025924; Sun, 15 Sep 2013 22:56:16 +0300
X-CheckPoint: {523610E0-0-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0347.000; Sun, 15 Sep 2013 22:56:15 +0300
From: Yoav Nir <>
To: Yaron Sheffer <>
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: AQHOskdo5dKKYJ0xmEuWRIX4Ztx5/ZnHBG8A
Date: Sun, 15 Sep 2013 19:56:15 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 19:56:38 -0000

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.


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