Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group

Hubert Kario <hkario@redhat.com> Wed, 05 November 2014 12:20 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552DE1A0075 for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 04:20:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.496
X-Spam-Level:
X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwTV3GLNMT3j for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 04:20:27 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF451A887A for <tls@ietf.org>; Wed, 5 Nov 2014 04:20:26 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA5CKPkU003198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tls@ietf.org>; Wed, 5 Nov 2014 07:20:26 -0500
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA5CKOu3031950 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Wed, 5 Nov 2014 07:20:25 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 05 Nov 2014 13:20:23 +0100
Message-ID: <4568901.9euKC2mo8R@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-203.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com>
References: <8E6B8F53-9E8C-46B2-A721-85E918576F3A@ieca.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EVmZnj121cuRfJ9sLTzg35NXeDw
Subject: Re: [TLS] STRAW POLL: Size of the Minimum FF DHE group
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 05 Nov 2014 12:20:29 -0000

On Tuesday 04 November 2014 12:49:21 Sean Turner wrote:
> Hi!
> 
> At the TLS Interim meeting in Paris, the WG discussed the FF DHE draft
> (https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/)  The
> chairs would like to poll the WG on one of the issues in the draft namely
> the size of the minimum group.
> 
> The draft currently includes a minimum group size of 2432 but the WG also
> discussed 2048.  Groups smaller than 2048 were discounted for a standards
> track document as too weak for use but might be documented in a separate
> “historic” draft.  To help us reach consensus on this point, please reply
> to this email indicating whether you favor a “2048" or “2432” minimum group
> size.  Note we’re also looking to specify the smallest number of options
> for groups as is acceptable - i.e., we’re not looking at specifying both
> 2048 and 2432.

2048

This is of issue only to legacy applications that don't implement ECC, so 
higher security margin is of limited importance.
That's a work factor difference of around 10 bits, that's rather close to the 
difference between 3DES and AES128...

implementations of "round" numbers are much more likely to be optimised for 
higher performance in currently deployed software

It matches currently deployed base (around 4% of TLS-enabled Alexa top 1 
million servers use 2048 bit DH, while the ones that use any size between 2048 
and 3072 can be counted on one hand)

I don't know if there are HSMs that are used for DH key exchange, but of ones 
that I used, all supported only very specific RSA key sizes.

-- 
Regards,
Hubert Kario