Subject: RE: [TLS] Any advice regarding frequency of generating newDHparameters?

From: Peter Williams <[email-masked]>
Date: Mon, 18 Dec 2006 15:40:21 -0800

lets put this in standards group issue/resolution format.
 
     Q1: Is anyone proposing that the ephemeral DH process be removed from the TLS 1.2 I-D?
 
     Q2: Is anyone proposing that the classical DH process in TLS 1.2 I-D be augmented to signal 
    DH-parameters (i) whose values are standardized, and (b) are not signaled via certs?
-------
 
N.B.
 
The whole point of ephemeral DH is realtime generation of the public/private key, with 
realtime RSA signing of the public key. The result acts like a cert, dynamically issued by 
the SSL endpoint, under the control authority of the CA issuing the RSA signing cert. This 
dynamic "cert" is never subject to PKI controls like EKU, OCSP, etc - not being created
by an issuing authority. How it is used in subsequent SSL sessions... is upto 
your imagination.
 
There was a little RSA cryptopolitics going on, if anyone is interested. Netscape didn't have the
library or adminwebsitecapability to have a distinct signing (vs. key transfer) RSA key, for all
its various production servers (doing nntps, ftps, https). It thus forced one RSA key to have 
the possibility of performing its full, dual reversible functions, something the cryptopolitics of the 
day was attempting to subvert.

> Subject: RE: [TLS] Any advice regarding frequency of generating newDHparameters?> Date: Mon, 18 Dec 2006 09:06:17 -0500> From: [email-masked]> To: [email-masked]> CC: > > > Protocols such as IKEv2 use the same modulus (p) and generator (g)> > forever (but of course generate new public/private values), since > > they don't actually send the p/g values, but just the group number.> > Yes. Note that they offer more than one group.> > > IMHO it probably would make sense for a TLS implementation to use > > one of the groups specified in RFC 4306 or 3526, instead of e.g. > > generating a random prime p (generating random primes is kind of > > slow, and then you have to worry about RFC 2785 etc.). > > Just one group? Or allow choosing the group like in IKE?> > > (Would others agree with this recommendation? Should we add it > > to the TLS 1.2 spec?)> > Makes perfect sense to me!> > > > -----Original Message-----> > From: ext Mike [mailto:[email-masked]] > > Sent: 16 December, 2006 02:56> > To: [email-masked]> > Subject: [TLS] Any advice regarding frequency of generating > > new DHparameters?> > > > Hi,> > > > I'm wondering if there is any generally accepted advice> > on how long to use the same Diffie-Hellman parameters in> > a TLS server. Does the answer depend on whether the> > server generates a new public key from the parameters> > for each new connection (mine does)?> > > > Thanks for any insight,> > > > Mike> > > > _______________________________________________> > TLS mailing list> > [email-masked]> > https://www1.ietf.org/mailman/listinfo/tls> > > > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls> > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Check the weather nationwide with MSN Search: Try it now!
http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Mon, 18 Dec 2006 15:55:18 -0800

>      Q1: Is anyone proposing that the ephemeral DH process be removed 

No, I merely asked how often I should generate new parameters.  If
anything I think there should be discussion in the security issues
section suggesting a minimum size for p.  EDH is superior to RSA
in that CA key compromise does not lead to compromise of any prior
or even future TLS session.

Mike

---

From: Mike <[email-masked]>
Date: Mon, 18 Dec 2006 17:38:01 -0800

> EDH is superior to RSA

Instead of "CA key", I meant to say "server private key".

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Dec 2006 15:53:47 +0100 (MET)

> Instead of "CA key", I meant to say "server private key".

At least not for passive attacks, that is, I assume.

Complete man-in-the-middle (i.e. active attack) using a compromised
servers private key is still possible.

The same would be achievable with RSA ephemeral keys.
I wonder why ephemeral RSA keys are prohibited for regular
RSA key exchange algorithms.  Ephemeral RSA keypairs with the same
size as the server's cert would provide perfect forward secrecy
and protection against passive attacks -- and the entire code
necessary to implement this is already there.

-Martin