[TLS] Re: Short Ephermal Diffie-Hellman keys

[Simon Josefsson <simon at josefsson.org>]

<Pasi.Eronen at 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 at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls