> -----Original Message----- > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > Sent: Monday, November 12, 2007 1:38 PM > To: Fries, Steffen > Cc: Dan Wing; Eric Rescorla; IETF SIP List > Subject: Re: [Sip] media-security-requirements and lawful intercept > > At Mon, 12 Nov 2007 12:30:34 +0100, > Fries, Steffen wrote: > > > > > > 4. I don't actually think there's any protocol > engineering required > > > > here. The problem of how to arrange for TLS traffic key > > > disclosure > > > > to third parties without modifying the wire protocol has > > > been quite > > > > extensively studied and a broad variety of approaches exist, > > > > covering a range of levels of active/passiveness, > real-timeness, > > > > cooperation from the endpoints, etc. Techniques > exist which are > > > > significantly better than those indicated by Dan. > For instance, > > > > consider that if you have the TLS server's private > key and you're > > > > doing RSA, you can do completely passive inspection with no > > > > cooperation from either side. > > > > > > I am aware of that technique; however, for SIP calls with > the offer > > > in the in the Invite, you could only intercept outgoing calls, > > > because incoming calls cause your intercept target to be the TLS > > > client. I don't believe that technique is viable to meet R24. > > > > > > > Another example would be [GBGP03]. > > > > > > I was not aware of that technique; thanks for the pointer. > > > That technique seems useful. > > > > > > (Direct link, > > > http://crypto.stanford.edu/~pgolle/papers/escrow.pdf) > > > > This is an interesting paper, but doesn't it require also > some form of > > cooperating client (as required in > draft-wing-sipping-srtp-key) as it > > would be necessary to exchange at least one of the SSL libs of the > > clients? > > I'm not aware of any technical mechanism for secure doing > end-to-end encryption of traffic that also allows key > disclosure to some external entity in the middle without > modifying the client (SDESCRIPTIONS doesn't require > modification this because it's not e2e secure: it > *always* discloses the key to an intermediary). agreed
> My point was not that one ought to pursue mechanisms allowed > key disclosure without modifying the client but that one > could design mechanisms that could be implemented solely in > the client software without explicitly modifying the wire > protocol. This means that clients (or, rather vendors) wish > wish to enable key disclosure can do so without any new > protocol design work from IETF. okay, understood. My fear here would merely be for the explicit case with DTLS, that if the general functionality of DTLS is included as part of the operating system, like it has been done in the past with SSL/TLS, the key disclosure may become available for every application using this library once somebody enabled key disclosure for one specific application (taken the approach described in the paper you referenced). If it is only an application specific functionality not influencing any other application running on the host, I'm with you. Steffen > > -Ekr _______________________________________________ Sip mailing list https://www1.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
