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). 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. -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
