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

james hughes <hughejp@mac.com> Wed, 18 September 2013 17:14 UTC

Return-Path: <hughejp@mac.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 C504211E810B for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 10:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.447
X-Spam-Level:
X-Spam-Status: No, score=0.447 tagged_above=-999 required=5 tests=[AWL=-3.294, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 byAYOfnejYsO for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 10:14:06 -0700 (PDT)
Received: from st11p06mm-asmtp002.mac.com (st11p06mm-asmtpout005.mac.com [17.172.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 61A3311E826E for <tls@ietf.org>; Wed, 18 Sep 2013 10:14:04 -0700 (PDT)
Received: from [10.0.1.4] (unknown [184.69.15.210]) by st11p06mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTB00CX7ZV705B0@st11p06mm-asmtp002.mac.com> for tls@ietf.org; Wed, 18 Sep 2013 10:14:02 -0700 (PDT)
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-1308280000 definitions=main-1309180084
Content-type: multipart/alternative; boundary="Apple-Mail=_9BB56C4A-6A24-4E69-8041-CB8237894538"
MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: james hughes <hughejp@mac.com>
In-reply-to: <4EEA8B22-183D-41E0-A7E2-E784A92F7185@mac.com>
Date: Wed, 18 Sep 2013 10:13:54 -0700
Message-id: <F221C62A-6642-4F7E-902E-9517840096F1@mac.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>
To: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
X-Mailer: Apple Mail (2.1508)
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:14:19 -0000

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.

>  and perhaps ECC patents will expire by then? 


But the trust in ECC will not have recovered by then.

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. 

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? 

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"?