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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Sun, 22 September 2013 21:28 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 DDBFF21F9D1F for <tls@ietfa.amsl.com>; Sun, 22 Sep 2013 14:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24]
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 GbKxvcJTvk17 for <tls@ietfa.amsl.com>; Sun, 22 Sep 2013 14:28:58 -0700 (PDT)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 01A5C21F9D1E for <tls@ietf.org>; Sun, 22 Sep 2013 14:28:57 -0700 (PDT)
Received: by mail-ea0-f175.google.com with SMTP id m14so1327982eaj.34 for <tls@ietf.org>; Sun, 22 Sep 2013 14:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=+Xi5UsOvh4Ruu688ps7WoAAk2dzPha98//LJJuUWE2Q=; b=ut6OIDLiTSYyHTKz7x3rz+n0HjlkSJ4rptqCPLAbhtMrOMPkAjHRc5cF6QlH4N3eQl sqkSSYUtnrrCmL3e5sCQ7cFYsCywIsNZlFxoo0XCiFlMKGmu0O74hDcv9DZLXZxBW4Cr kxkU8wkgvsi2X+rxNEugRuLVEN4YWS1TvxKh8+xTN165H5zQCl/8egIHs4+mqNGyx3s0 zf0CD1r70UVomYilFLb6tCrnC/hyGFkF6g4pAHm49b8CiFQ7/g2eWQF//N3BRTekQPbU aJ4Vj2mJuyQoFNQGyYpsgA+XUEO8InJH1JlrcOt2YxuiowRiagRkqMJWawA1ws+KOsUf 6ftA==
X-Received: by 10.14.113.137 with SMTP id a9mr30859843eeh.3.1379885337058; Sun, 22 Sep 2013 14:28:57 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id k7sm36928186eeg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Sep 2013 14:28:56 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <523F6112.9040306@gnutls.org>
Date: Sun, 22 Sep 2013 23:28:50 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
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.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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: Sun, 22 Sep 2013 21:28:59 -0000

On 09/21/2013 08:57 AM, james hughes wrote:

> "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).
[...]
> Why does the burden of proof seem to be so high on the cryptographers
> to prove that an algorithm (or key size) is not secure enough? Stated
> differently, why must crypto community, who knows something is, or
> will soon be, breakable have to shame the standards bodies into
> reasonable action with a pie in the face  [for the non-english
> speakers, for a definition of "pie in the face" see
> http://en.wikipedia.org/wiki/Pieing]?

I couldn't agree more. The fact that 1024-bits is the only option in
some implementation that doesn't make it the best practice. It was the
best practice 13 years ago.

What would be reasonable would be to keep 2048 as the recommended value
(so the implementations with issues have an incentive to fix) and
additionally mention the issues that some implementations have, and
recommend that if short term protection is sufficient 1024-bit DH groups
offer better compatibility. Mentioning anything else than that will
mislead non-crypto experts (all key length studies list 1024-bit DH
groups as suitable for short-term data protection, nothing more).

regards,
Nikos