Dan, Thanks for classifying the options. I just wonder whether there is a subdivision of 3. With 3, I could negotiate keys with a decrypting relay, but I really have no idea what happens beyond that relay. Or I can negotiate keys end-to-end where media is sent via a non-decrypting relay, which copies the encrypted media to a decrypting entity (not necessarily a SIP entity) to which I have disclosed the key. That decrypting entity could be in even be in the domain of the law enforcement authorities rather than a SIP service provider. Of course, verification that the key is correct then has to be done by the decrypting entity more or less in real time, with feedback to the SIP service provider if it believes the key to be incorrect, so that the call can be stopped. Did you have one of both of these in mind for option 3?
John > -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: 08 November 2007 18:33 > To: 'Ted Hardie'; 'Paul Kyzivat'; 'Dean Willis' > Cc: 'IETF SIP List'; Elwell, John > Subject: RE: [Sip] media-security-requirements and lawful intercept > > Ted, > > > ... > > Speaking for me, personally, the costs are too high. If the > > working group does decide to move forward here, I will strongly > > urge early review by the broader IETF community, as the > consequences > > of this decision are not light. > > ... > > Thanks for your email. I agree this needs wider discussion and the > WG (and probably RAI as a whole) needs to decide what it wants to do. > > The wider consequence, however, is not increased "epic invasion of > privacy", as you state. The wider consequence is that, without a > suitable mechanism that meets the needs of LI for SRTP, networks > subject to LI will only ever be able to do RTP. The choices, as I > see them, are (in order of least secure to most secure): > > 1. everyone can listen to the call. This is what we have today > with RTP. This allows 'epic invasion of privacy' by all > parties (governments, criminals, and anyone who is able to > receive your RTP) > 2. every SIP entity learns the SRTP keys. This is what would > happen with Security Descriptions. This allows 'epic > invasion of privacy' by any party that has control of any > SIP entity your Invite (or its response) traversed. That > control could be legitimate or could be illegitimate > (government or criminal hacked into the SIP proxy). > 3. only a specific SIP entity learns the SRTP key. This is > what would happen in the two techniques I proposed at the > beginning of this thread. This allows 'epic invasion of > privacy' by any party that has control of that specific > SIP entity. That control could be legitimate or could be > illegitimate (government or criminal hacked into that > specific SIP proxy). > 4. IETF sticks with only doing DTLS-SRTP and provides no > guidance for how to meet LI requirements. > > The choice, as IETF has always seen it, is to stick with IETF's first > principles [RFC1984, RFC2804] which is end-to-end crypto is > best (4) and > market and legal requirements are not relevant to IETF's > standards. I agree > it is a laudable and worthy goal. I could even agree that we > should leave it > to other SDOs, who deal more closely with LI requirements, to > determine how > those LI requirements can be met. > > Yet, IETF has also said that IETF owns the SIP standards (and related > standards). > > Taking your suggestion would mean we do (4) and have other > SDOs decide if and > how to accomplish a weaker, LI-friendly solution (1, 2, or > 3), and IETF should > not provide guidance for the most secure (3) of those > remaining LI-friendly > approaches. The result is undesirable: millions of users > will be unprotected > because they will only have plain RTP (1) or they will be > vulnerable to every > SIP proxy on their path (2); (3) is difficult, and (4) will > be undeployable by > licensed providers in many countries around the world. > > -d > _______________________________________________ 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
