RE: [TLS] Re: TLS 1.2 draft

Simon Josefsson wrote:

> Generating a fresh DH ephemeral with each key exchange would 
> deplete the entropy in many RNG's.

The normal RSA ciphersuites require far more bytes from PRNG for 
each key exchange (although only on the client side), and I 
haven't heard that this would be a significant problem.

<snip>
> I can't find an appropriate section, but section 8.1.2 seems as good
> as any, so I suggest adding this to the end of it:
> 
>    When ephemeral DH parameters are needed, they SHOULD be
>    re-freshed with some interval appropriate for the local
>    environment.  This MAY be for each new key exchange, but MAY also
>    be each day, week or month.
> 
> That's quite fuzzy, but I'm not sure there are any good
> recommendations on this.  In GnuTLS, I think we recommend to change
> the DH ephemeral somewhere around each day or week.

Considering that generating fresh DH private value costs about 
the same as one TLS handshake with DHE, I'd say even a day
would be a very large interval.

IKEv2 took the view that since this doesn't affect interoperability, 
there's no need to mandate anything in the spec (RFC 4306, Section
2.12).

However, maybe some guidance would be helpful (especially if there
really are implementations that store the "ephemeral" DH key in
a file!). Earlier, I also suggested that we should recommend *against*
generating new DH domain parameters:

http://www1.tools.ietf.org/wg/tls/trac/ticket/35

Eric responded that this is not specific to TLS, and could be a 
separate document. That's of course true, but currently we don't 
have any normative dependency to documents that explain 
how to do DH securely. And I do agree with the sentiment expressed 
in IETF67's SAAG presentation that RFCs should include advice on 
how to implement them securely (especially for things that
people earlier have gotten wrong).

Best regards,
Pasi

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