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

Yoav Nir <ynir@checkpoint.com> Wed, 18 September 2013 19:47 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 C576B11E8140 for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 12:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.934
X-Spam-Level:
X-Spam-Status: No, score=-9.934 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751]
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 vsOcSYdC08dK for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 12:47:31 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BE34311E825A for <tls@ietf.org>; Wed, 18 Sep 2013 12:47:05 -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 r8IJkvK7009334; Wed, 18 Sep 2013 22:47:01 +0300
X-CheckPoint: {523A0331-7-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; Wed, 18 Sep 2013 22:46:57 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: james hughes <hughejp@mac.com>
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac60VQbt5dKKYJ0xmEuWRIX4Ztx5/f//0Y0AgABG7YCAAAGHgIAAHcMAgAAI9ICAAAfWAIAABcOAgAAcUICAAAivAA==
Date: Wed, 18 Sep 2013 19:46:57 +0000
Message-ID: <E9939285-E47A-4D4C-8EA3-5F2924559897@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz> <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com> <5239B845.6010606@gmail.com> <958F40E0-8978-4C4F-BB2E-2519B66470D9@ll.mit.edu> <4EEA8B22-183D-41E0-A7E2-E784A92F7185@mac.com> <F221C62A-6642-4F7E-902E-9517840096F1@mac.com> <8E95757A-5DBB-4FBC-8EBC-2F28F47903CB@ll.mit.edu> <2EF88965-50F2-44C3-862F-F9B92BD51D66@mac.com>
In-Reply-To: <2EF88965-50F2-44C3-862F-F9B92BD51D66@mac.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.158]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: multipart/alternative; boundary="_000_E9939285E47A4D4C8EA35F2924559897checkpointcom_"
MIME-Version: 1.0
Cc: "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: Wed, 18 Sep 2013 19:47:37 -0000

On Sep 18, 2013, at 10:15 PM, james hughes <hughejp@mac.com<mailto:hughejp@mac.com>>
 wrote:


On Sep 18, 2013, at 10:34 AM, "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu<mailto:uri@ll.mit.edu>> wrote:

If you think that in 5 years 1024-bit DH will be trivially crackable - I'd like to see some evidence to support it.

There is a different between "trivially crackable" and routinely exploitable. In 5 years this will be routinely exploitable.

Based on what? There's been a paper ([1]) describing how to produce a SHA-1 collision in 2^61 steps for two years, and nobody's produced a collision yet. This should be within the powers of a moderately well-funded company or university, not just government agencies. Sure, the NSA has the resources to produce a SHA-1 collision. But if they had to produce one for *each* session they wanted to break, they would have to be very picky with choosing the sessions that they break.

1024-bit RSA and DSA are usually considered equivalent to 80-bit security, so half a million times more difficult to crack than producing a SHA-1 collision (an effort no civilian has yet dared to take). DHE with 1024-bit keys means that our favorite pervasive attacker would need that much effort to crack a single connection. It's much better to deploy that than to not deploy 2048-bit DHE because so many of the servers and clients don't support it.


It seems to me that the standards process does not need NSA to subvert the process, the standards people seem to be doing this fine by themselves. Anyway, speaking as someone working in this field (more factoring than discreet log) the professional recommendation is 2048.

Yes, and where it's possible (RSA keys) we've all migrated. But the professional recommendation that I'm hearing is to move to ECC.

I am not baiting here, but the argument that 2048 is "too much" given that a PC can do a complete authenticated PFS key exchange in 3ms of CPU time seems "interesting".

Moving from 1 ms to 3 ms is trivial for a client, but may require buying more hardware for the server. As someone in the field of selling hardware, that's great! But it does slow adoption.

But that is not the argument you hear from me. My argument is that it's pointless to change implementation to support a better DHE, when (a) the current DHE implementation is OK for now, and (b) ECDHE is the future and already implemented in most codebases.

Yoav