[TLS] Re: Short Ephermal Diffie-Hellman keys

Simon Josefsson <simon@josefsson.org> Tue, 15 May 2007 16:13 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnze5-000344-T9; Tue, 15 May 2007 12:13:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnze3-00033m-Mz for tls@lists.ietf.org; Tue, 15 May 2007 12:13:03 -0400
Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnze2-0002d6-7y for tls@lists.ietf.org; Tue, 15 May 2007 12:13:03 -0400
Received: from mocca.josefsson.org ([83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4FGCoo9007430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 May 2007 18:12:57 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Pasi.Eronen@nokia.com
References: <op.tsa3n9ttqrq7tp@nimisha.oslo.opera.com> <46488F24.4020304@pobox.com> <B356D8F434D20B40A8CEDAEC305A1F24041FA7FF@esebe105.NOE.Nokia.com> <4649A374.8040805@drh-consultancy.demon.co.uk> <87y7jqckh2.fsf@mocca.josefsson.org> <B356D8F434D20B40A8CEDAEC305A1F2404229A6B@esebe105.NOE.Nokia.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:070515:tls@lists.ietf.org::AGOZ24R6cM2lKKxs:1lWv
X-Hashcash: 1:22:070515:pasi.eronen@nokia.com::4Ai+2aulNt9bxdaL:7UMT
Date: Tue, 15 May 2007 18:12:50 +0200
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2404229A6B@esebe105.NOE.Nokia.com> (Pasi Eronen's message of "Tue\, 15 May 2007 16\:50\:13 +0300")
Message-ID: <877iraawvx.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: tls@lists.ietf.org
Subject: [TLS] Re: Short Ephermal Diffie-Hellman keys
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

<Pasi.Eronen@nokia.com> writes:

> Simon Josefsson wrote:
>
>> Some applications that use GnuTLS (I believe Exim is an example)
>> have a separate script invoked once every day (or similar) to
>> re-generate the DH parameters.  This approach works fine even if
>> getting the entropy is a bottle-neck, since it allows servers to
>> continue to run using the earlier DH parameters until the new
>> parameters have been generated.
>
> BTW, why do you generate new DH parameters in the first place?

GnuTLS doesn't -- external applications, notably Exim, do it.  However,
I have not idea why they do it.  There are some discussion about this
behaviour in section 2.2.3 of:

http://pkg-exim4.alioth.debian.org/README/README.Debian.html#id224002

Frankly, I'm not sure I really understand what they are doing or why.

> Earlier I suggested that TLS 1.2 spec should probably recommend just
> hardcoding some of the groups from RFC 3526 (i.e., recommend against
> generating DH parameters). This would simplify code and provide less
> opportunities for getting things wrong (e.g. very small primes seen by
> Yngve; small subgroup attacks; etc.).
>
> http://www1.ietf.org/mail-archive/web/tls/current/msg01115.html

I think we would need solid support from the cryptographic community to
change this.

Regenerating new DH parameters appear to me, if they are computed
correctly, to potentially offer one additional wall of protection.

The risk is if the parameters are not computed correctly.  But that risk
have to be weighted against the risk of someone exploiting the fact that
many D-H exchanges on the Internet uses the same parameters, and does so
over a multi-year time period.

Personally, I'm leaning towards reviewing the code to generate D-H
parameters, and to recommend administrators to re-generate parameters
every X days.  Instead of putting all trust in one D-H parameter.

/Simon

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls