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

Michael Ströder <michael@stroeder.com> Sat, 21 September 2013 13:37 UTC

Return-Path: <michael@stroeder.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 5AD0C11E81C5 for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 06:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 6hZUpw6z3z9x for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 06:37:29 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id D4FEB11E81C3 for <tls@ietf.org>; Sat, 21 Sep 2013 06:37:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 64712602E9; Sat, 21 Sep 2013 15:37:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJCKGGbMc48F; Sat, 21 Sep 2013 15:37:20 +0200 (CEST)
Received: from nb2.stroeder.local (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id B94D0602DC; Sat, 21 Sep 2013 13:37:19 +0000 (UTC)
Message-ID: <523DA10F.7010308@stroeder.com>
Date: Sat, 21 Sep 2013 15:37:19 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20
MIME-Version: 1.0
To: james hughes <hughejp@mac.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com>
In-Reply-To: <A3161699-0975-403C-B9C1-8BE548062949@mac.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030302050703090805030003"
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 13:37:34 -0000

james hughes wrote:
> 
> On Sep 19, 2013, at 2:56 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>; wrote:
> 
>> "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>; writes:
>>
>>> 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.
>>
>> Exactly.  We don't need theoretically perfect security in ten years when we've
>> finished arguing about it and have upgraded every system on the planet to
>> support it, we just need good enough right now.  That's DH-1024, and when we
>> have that turned on everywhere we've got some breathing space to worry about
>> what to do next.
> 
> 
> "theoretically perfect security in ten years", really? You think that 1024
> is "good enough"? I do not know a single reputable source that says 1024
> bit is "secure" (outside the people on this list). Not even NIST. If you
> are going to step forward for PFS, do it right. Raise the D-H key size to
> 2048. 2048 bit is required now and will give you security for only 7 years
> (Thank you France).

I personally would prefer D-H key size 2048 bit everywhere and I don't worry
about performance. (Did you ever notice that most SSL/TLS connections are
going to ad servers?)

But the problem in the context of draft-sheffer-tls-bcp is that existing
implementations do not support D-H key size of 2048 bits. And the author(s) of
this draft take this fact to rule out DH completely and recommend EC-based
cipher suites. IMHO ECs seem to be a can of worms. I don't trust those
complicated cipher suites.

Ciao, Michael.