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

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 18 Dec 2006 09:06:17 -0500

> 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

---

From: Peter Williams <[email-masked]>
Date: Mon, 18 Dec 2006 16:42:57 -0800

The answer formally is: its up to the CA issuing the DSA/RSA cert (with a signing EKU). This
CA  authorized the endpoint to mint this message. You wont see this in any spec, to 
my knowledge. But its consistent with the intent. 
 
If you have a liberal CA or NO CA, then your endpoint make its own groups/keys on 
the fly according to its own rules. the Endpoint policy gets to choose all matters of
key. It would also specify the precise format and encoding rules for the opaques, then.
 
--------------
 
Minting ephemeral key management messages would normally be controlled by 
the PKI. In the SSL3 era, for PKI ciphersuites, a PKI is in charge of the assurance 
level attained by the channel. The CA particularly controls all matters of key, key 
size and algorithm selection, opaque definitions - all of which obviously then controls 
the security levels of  each of the the 4 channels independently as a function then 
of the PRF and the session key derivation functions(s).
 
So. in SSL3, you would really only generate ephemeral key according to endpoint control 
only when (a) there is no PKI  controlling a PKI ciphersuite (b) when a PKI-controlled
server has selected that server authentication should not be performed (assuming
the PKI authorizes this selection option)
 
In the latter case, how the client verifies the signed key is NOT specified within SSL. One
unstated implication is that its handled by the server hello sessionid resumption process, where
the client repurposes its knowledge of an earlier server authentication in the cascade
of resumption handshakes. Other options exist to consulting the cascade, however. Remember,
SSL3 allows for interleaving application, std handshake, and custom client protocol record
types, if session state is active.
 
Its a designers toolkit. Use it, fully!

> Date: Mon, 18 Dec 2006 15:55:18 -0800> From: [email-masked]> To: [email-masked]> Subject: Re: [TLS] Any advice regarding frequency of generating newDHparameters?> CC: > > > Q1: Is anyone proposing that the ephemeral DH process be removed > > from the TLS 1.2 I-D?> > 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> > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
All-in-one security and maintenance for your PC.  Get a free 90-day trial!
http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=wl_wlmail

---

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

I took the discussion private. However Ill repeat one element publicly:-
 
"                                              I have about 200 [RSA smartcards] in my garage, if anyone in the US wants them. Ihave 50k in chip form still on the reel, if someone in the US wants to build a key cracker. Ill donatethem to a[n accredited] university."

> Date: Mon, 18 Dec 2006 17:41:10 -0800> From: [email-masked]> To: [email-masked]> Subject: Re: [TLS] Any advice regarding frequency of generating newDHparameters?
_________________________________________________________________
Use Messenger to talk to your IM friends, even those on Yahoo!
http://ideas.live.com/programpage.aspx?versionId=7adb59de-a857-45ba-81cc-685ee3e858fe

---

From: Peter Williams <[email-masked]>
Date: Sat, 23 Dec 2006 11:54:33 -0800

I've been looking at the ephemeral mode of Fortezza_dms (in SSLv3), following up the thread on DH/RSA ephemeral. First lets remember, the dms ciphersuites use mechanisms that work differently to DH/RSA features (and the various RSA-using (std and locally-defined) ciphersuites that construct X.800 mechanisms out of these X.800 features). 
The mechanism of "key agreement" is avoided in the DMS variant of  KEA, being replaced by "TEK agreement" - a wrapping mechanism. The clientside process computes the TEK, wraps SSL session (encryption mechanism) keys, where the server side KEA math exists only to unwrap them given access to the kea public key in the client cert. Pre-master secrets are then swapped around under the TEK wrapping, to keep the rest of the SSL state machine happy and to generate the MAC session (integrity mechanism) keys/IVs as normal.
The interesting part is that we can ephemerally generate the client's KEA public key, generated client side. In servekeyexchange, r&s are unique to each session handshake already, controlling TEK generation, without regard to the client/server nonces (I assume).
If would now be interesting to go further now, and build in further use of several unique UKM rA values into the handshake, and generate a series of CEKs/IVs for encrypting different custom record_types within the record-layer, each one extending connection state in some way. Perhaps the derived value(s) could be just different record_type_IV(s), not CEKs, extending session state by 2*n IVs, one set per custom record_type, for client.write.record_type_idX, server.write.record_type_idX. 
If we generalize this now for schemes other than wrapping , and DMS-styled KEA, we allow for designers to customize/extend the final protocol, per-connection. This can allow folks to add in their user auth schemes on "their record layer client protocols" , even those that influence the enc and mac keys/ivs per connection. One can argue all day that those scheme are poor (too many extra round trips, etc), but… that’s for the market to decide, not IETF. Why anyone cares these days about an extra round trip, I don't know.
_________________________________________________________________
Get the Live.com Holiday Page for recipes, gift-giving ideas, and more.
www.live.com/?addtemplate=holiday