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

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Wed, 18 September 2013 17:34 UTC

Return-Path: <prvs=29737ce98b=uri@ll.mit.edu>
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 D33D411E810B for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 10:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.653
X-Spam-Level:
X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-3.395, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
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 5GubaNOxqjhR for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 10:34:37 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 320B811E80E4 for <tls@ietf.org>; Wed, 18 Sep 2013 10:34:36 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8IHY6Ot002348; Wed, 18 Sep 2013 13:34:35 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: james hughes <hughejp@mac.com>
Date: Wed, 18 Sep 2013 13:34:31 -0400
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac60lVUp7r4tWQATQ+uVwEBw3sx87g==
Message-ID: <8E95757A-5DBB-4FBC-8EBC-2F28F47903CB@ll.mit.edu>
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>
In-Reply-To: <F221C62A-6642-4F7E-902E-9517840096F1@mac.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail=_44B2CA37-DAE2-4612-8537-EBFF198561BD"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-18_08:2013-09-18, 2013-09-18, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309180087
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 17:34:42 -0000

On Sep 18, 2013, at 13:13 , james hughes <hughejp@mac.com>; wrote:
> On Sep 18, 2013, at 9:13 AM, "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>; wrote:
> 
>> I believe that for ephemeral DH 2048 bits is a huge overkill. In fact, 1536 is likely to be an overkill as well. I think 1280 bits would be sufficient for the next few years,
> 
> 
> Why are we suggesting something that will be sufficient for the next few years? IMHO, it will take a few years to implement this change. By the time this has been adopted, will be in trouble again.

I personally think that for *ephemeral* DH even 1024 bits still is enough. And would *much* prefer having PFS now with individual session keys at somewhat greater risk, over a system that is very secure and completely useless because nobody bothered to deploy it.

>>  and perhaps ECC patents will expire by then? 
> 
> 
> But the trust in ECC will not have recovered by then.

I trust ECC. My only problem with it is its set of patents. Whoever doesn't trust ECC - feel free to go to 10K RSA keys. :-)


> Is the complaint speed?  We are arguing about a key exchange that goes from ~1ms to ~3ms. Yes, this is more but this is absolutely not a problem for PCs or even phones or tablets especially in the light of session keep alive and other techniques that allow a key exchange to last a while. 

What about servers? An individual PC (and its user :) with one TLS connection can afford 30 seconds of session establishment time, no big deal. A server might not like it.


> On Sep 9, 2013, at 7:30 PM, Michael Ströder <michael at stroeder.com> wrote:
> 
>> MBA-2:tmp synp$ openssl speed dsa1024 dsa2048
> […]
>>                  sign    verify    sign/s verify/s
>> dsa 1024 bits 0.000445s 0.000515s   2247.6   1941.8
>> dsa 2048 bits 0.001416s 0.001733s    706.4    577.2
> 
> 
> Is the complaint that the server load is too high? 

It probably is. But I'll let Michael speak for himself. ;)

> Why are you suggesting such a partial step in light of Moore's law? If 1024 is not large enough, how long will 1200 last? Do we think that Moore's law is not relevant (massively parallel operations already dominate the time to recover a key, so single thread performance is a moot point). Do you assume that the value of data goes down so fast that using a key that will be easy to recover in 5 years is "good enough"?

To repeat myself, I personally think that 1024 bits is large enough for *ephemeral* DH. And yes, I assume that value of individual sessions would go down fast enough, faster than the ability to scoop them all and crack in bulk. So with PFS, an ordinary session's security lifetime of 5 years (please note, that we don't know whether in 5 years 1024-bit DH would be crackable that easily, let alone 1280) would be fine with me. If you think that in 5 years 1024-bit DH will be trivially crackable - I'd like to see some evidence to support it.