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

Yoav Nir <ynir@checkpoint.com> Sat, 21 September 2013 19:15 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D285821F9D31 for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 12:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.338
X-Spam-Level:
X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5N1jKB19Zbq for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 12:15:40 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8867121F9D33 for <tls@ietf.org>; Sat, 21 Sep 2013 12:15:39 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8LJFWD1023318; Sat, 21 Sep 2013 22:15:36 +0300
X-CheckPoint: {523DF054-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sat, 21 Sep 2013 22:15:33 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "Michael D'Errico" <mike-list@pobox.com>
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac61Hnof5dKKYJ0xmEuWRIX4Ztx5/QBYDy2AABRpPoAABVvNgA==
Date: Sat, 21 Sep 2013 19:15:31 +0000
Message-ID: <8B499338-45C3-4680-892B-880135BEF7F3@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com> <523DCC5D.9040707@pobox.com>
In-Reply-To: <523DCC5D.9040707@pobox.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.24.217]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <AD72757D754924449F6E65ED67A69539@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [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: Sat, 21 Sep 2013 19:15:46 -0000

On Sep 21, 2013, at 7:42 PM, Michael D'Errico <mike-list@pobox.com>; wrote:

> James,
> 
> The problem is that there apparently is lots of TLS code which can only handle
> 1024-bit DH parameters and would break if a server sent larger parameters.
> 
> The idea that 1024 is big enough stems from the fact that many many connections
> don't use DH at all, and would benefit if RSA was replaced by EDH.  Thus an
> attacker would need to break 1024-bit DH for each connection of interest.

Many websites cannot deploy 2048-bit EDH because of limitations in their software, and those who can won't, because of interop issues with many of the browsers that are out there.

OTOH 2048-bit RSA keys work well pretty much everywhere. So we're left with three choices:

 1. 2048-bit RSA keying. That's good security, but no forward secrecy.
 2. 1024-bit EDH, which gives forward secrecy, but may be breakable now or in 5 years.
 3. 256-bit ECDH, which gives forward secrecy, but some people feel uneasy about.

There are good arguments for and against each of these. I don't think we have a measure of whether it's easier to compromise a single RSA private key, or to calculate the DL for several 1024-bit EDH. I don't like how #1 creates an attractive, shiny target for attackers - a single file stolen from a web server, and all the traffic can be decrypted in Wireshark. OTOH assuming that an agency such as the NSA or French equivalent is able to break any 1024-bit EDH (that's not a given) they will be able to decrypt any single connection that they would like, but I don't believe they have the resources to decrypt every one. That's good for people who are not near the top of the list of threats to national security, but kind of not so good for those who are.

As I've said before, I'd rather we chose #3.

Yoav