Catching up on the list... At Sun, 17 Feb 2008 10:38:36 -0800, Dan Wing wrote: > > I would like to comment on PFS: > > > > The definition of the PFS in the Handbook of Applied > > Cryptography says: > > > > "A protocol is said to have perfect forward secrecy if compromise of > > long-term keys > > does not compromise past session keys." > > > > Now, there is only the question what "long-term key" means in > > this context. > > A DTLS-SRTP implementation would have both the server and client > cache the TLS Session Id, and remember the Session Id between > phone calls. This means the TLS security parameters and keys, > and thus the SRTP key (which is derived from the TLS security > parametersa and keys), are remembered between phone calls. > > As far as I am aware, there is no guidance for how long (hours) > this information is expected to be retained.
The guidance in TLS is 24 hours, but the usage model is totally different. To a first order, it's probably not worth trying to provide much guidance here, since the usage models in SIP vary so much. > > Hence, I am not so sure that PFS is destroyed with the > > ability to store > > session state. Furthermore, both parties can decide not to use it. > > If _either_ party stores the information, compromise of that > device (the one which stored the information) destroys PFS. So > even if I have configured my device to not store such information, > whoever I'm calling might not have configured it that way. There > is no mechanism, currently, to negotiate or communicate if you > want the remote party to cache TLS session information. Perhaps > RFC5077 could be used as the negotiation mechanism, such that > if both sides implement RFC5077 they are agreeing to caching > session information. I am not too interested in RFC5077's > ability to have one side (the TLS client) store the state, but > rather I am interested in a negotiation mechanism such that > both sides agree to break PFS. TLS already provides a facility for this: send a fatal alert. >From RFC 4346 S 7.2.2. Error handling in the TLS Handshake protocol is very simple. When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. Servers and clients MUST forget any session-identifiers, keys, and secrets associated with a failed connection. Thus, any connection terminated with a fatal alert MUST NOT be resumed. So, in this case you'd send close_notify with level fatal. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
