Eric Rescorla wrote: ...
> > > 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. Thanks. That would work but it is more fragile to rely on an end-of-session message compared to negotiating this up front. -d _______________________________________________ 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
