Re: [TLS] New Algorithm identifier for EDH > 1024 bits?

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 25 October 2013 03:19 UTC

Return-Path: <dkg@fifthhorseman.net>
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 281CB11E8296 for <tls@ietfa.amsl.com>; Thu, 24 Oct 2013 20:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 jNusU36eU2rm for <tls@ietfa.amsl.com>; Thu, 24 Oct 2013 20:19:06 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4211E8243 for <tls@ietf.org>; Thu, 24 Oct 2013 20:19:03 -0700 (PDT)
Received: from [192.168.42.101] (h-67-101-156-212.nycm.ny.dynamic.megapath.net [67.101.156.212]) by che.mayfirst.org (Postfix) with ESMTPSA id 60153F984 for <tls@ietf.org>; Thu, 24 Oct 2013 23:18:58 -0400 (EDT)
Message-ID: <5269E31F.3050203@fifthhorseman.net>
Date: Thu, 24 Oct 2013 23:18:55 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: IETF TLS WG <tls@ietf.org>
References: <20130930192805.1984A1A9C2@ld9781.wdf.sap.corp>
In-Reply-To: <20130930192805.1984A1A9C2@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2JREKWNIHPTIPDOQPWDCL"
Subject: Re: [TLS] New Algorithm identifier for EDH > 1024 bits?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: IETF TLS WG <tls@ietf.org>
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: Fri, 25 Oct 2013 03:19:12 -0000

[picking up a slightly stale thread, sorry for the lag]

On 09/30/2013 03:28 PM, Martin Rex wrote:
> Peter Gutmann wrote:
>> Could that be because of all of the TLS_DHE_DSS_* suites, with DSS limited to
>> 1024 bits so implementers also limited the matching DH to 1024 bits?  Just
>> wondering what other reason there could possibly be for artificially limiting
>> the size to 1024 bits.
> 
> The delay incurred by key generation maybe?
> 
> The app-supplied credentials are either RSA or DSA.  So for DHE,
> _everything_ has to be newly generated after process start and potentially
> in-band during the TLS handshake, unless the application caller has
> written some code that does generation out-of-band and installs/updates
> the DHE keying material regularly.

Just to clarify, for DHE not *everything* has to be generated at
connection time or even after process start.  The DH group itself (g and
p) can be chosen (and remain static) at the time of installation or
system configuration or service initialization, and only the secret key
needs to be selected at connection time.  DH parameter generation (group
selection) is a significantly more expensive than secret key selection.

There is quite a bit of software out there that allows the administrator
to select or configure the DH parameters that will be offered by the
server while doing ephemeral Diffie-Hellman without a large delay caused
by secret generation.

Regards,

	--dkg