Subject: Re: [Sip] R-REUSE, media-security-requirements

From: Eric Rescorla <[email-masked]>
Date: Fri, 07 Mar 2008 11:13:47 -0800

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 8 Mar 2008 19:58:13 -0800

Eric Rescorla wrote:

... 

> So, in this case you'd send close_notify with level fatal.

Thanks.

That would work but it is more fragile to rely on an end-of-session message
compared to negotiating this up front.

-d