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

Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 15 September 2013 19:11 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 33C8411E8198 for <tls@ietfa.amsl.com>; Sun, 15 Sep 2013 12:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9rxTQng9+nHm for <tls@ietfa.amsl.com>; Sun, 15 Sep 2013 12:11:23 -0700 (PDT)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 86EDB11E8192 for <tls@ietf.org>; Sun, 15 Sep 2013 12:11:23 -0700 (PDT)
Received: by mail-ea0-f175.google.com with SMTP id m14so1591134eaj.6 for <tls@ietf.org>; Sun, 15 Sep 2013 12:11:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=gL80D3oE6NP8yQg0R7VwVNb5L7fJ7sO/8MZGGp8YE9I=; b=ICatv3EiINuf7JLpl+Jh0ftZOaamTl9KUMgah8tofr+0oyHzSRG+FIuorP1sRNDLZ5 s6JirWo29657DN138+t1EpNPUwE4xeYn4Aoj6ll/09N8giR2keU+Sdo6qUTMKPClUq/u 85nuVToE9UxR4jZUxJg03Ostz6zs84xbI26z73PUBfdGk++6C49Ig1fubQXAD6eT/zmt HVCVfZf0wQnt8H/01fw24n6wra7XL6xrMG8gb521Q6VwVZJWQ3n5vdSUsAlyWGnTFIRE 0tbUb63nHcdR4aPW64zmOK1Hvg0GtGtcN/hrSEqQIMMXetaWMLGX8vHR/ENlY5dqP5J5 VnMg==
X-Received: by with SMTP id i49mr4899189eem.55.1379272282605; Sun, 15 Sep 2013 12:11:22 -0700 (PDT)
Received: from [] (bzq-79-181-201-37.red.bezeqint.net. []) by mx.google.com with ESMTPSA id n48sm35369925eeg.17.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 12:11:22 -0700 (PDT)
Message-ID: <52360658.7050203@gmail.com>
Date: Sun, 15 Sep 2013 22:11:20 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Sep 2013 19:11:25 -0000


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.