Peter, Thanks for reminding me of this critical point:
>Allowing lawful interception does not imply allowing anyone to intercept >the communication. You must have access control for the facilities >that allow lawful interception. This argument is simply not true given that all service providers lease national and international facilities as part of "the network". Data center capacity and services are also outsourced for countless reasons, so how do you know for sure where your data is and who exactly is in charge of it? Many vendors must also have access to critical network infrastructure, to make it work at all, all the time. I can only hope your trust in everybody in this very big ecosystem will not lead to disappointment and worse :-) (The missing smiley) Now if you work for a law enforcement agency or the government and your life really depends on communications security, I doubt you will trust your life or fortune to services that have intercept built in. Henry On 9/25/08 2:51 PM, "Schneider, Peter (NSN - DE/Munich)" <[EMAIL PROTECTED]> wrote: > See inline > > Peter > >> -----Ursprüngliche Nachricht----- >> Von: ext Dean Willis [mailto:[EMAIL PROTECTED] >> Gesendet: Donnerstag, 25. September 2008 21:32 >> An: Schneider, Peter (NSN - DE/Munich) >> Cc: [email protected] >> Betreff: Re: [Sip] Pub request for >> draft-ietf-sip-dtls-srtp-framework-03 >> >> >> On Sep 25, 2008, at 2:50 AM, Schneider, Peter (NSN - DE/Munich) wrote: >>> >>> Dean, I assume that you refer to the proposal to use SDES that is >>> discussed in 3GPP. However, 3GPP does not focus on that approach. >>> Other signaling path solutions are discussed in 3GPP that exclude >>> all intermediaries from access to the key. Clearly, >> allowing lawful >>> interception is a requirement for 3GPP, as is preventing "unlawful >>> interception". >> >> The two forms of interception cannot be technically differentiated. >> Anything that allows one allows the other. >> > Allowing lawful interception does not imply allowing anyone to intercept the > communication. You must have access control for the facilities that allow > lawful interception. Compare this with the authentication service described in > RFC4474 (SIP identity). Who controls that service, can mount a man in the > middle attack that cannot be detected by the means provided by DTLS-SRTP. > >> The USA has recently shown that it is possible to convert unlawful >> intercept into lawful intercept retroactively, despite a >> constitutional bar on ex post facto laws. If you're going to >> break one >> law, you might as well break 'em all, right? >> >>> The middlebox issue is NOT a pretense for allowing only weak >>> solutions for 3GPP. >> >> I believe you. >> >>> My proposals concerning the framework draft wouldn't make >> DTLS-SRTP >>> any weaker, right? >> >> I'm not sure. Security is such a frail thing, and it is easy for >> unintended consequences to occur. You may well be right, but I'm a >> little slow to commit. Further study is required. >> >>> And making DTLS-SRTP more adequate for 3GPP/TISPAN scenarios would >>> be a good thing, wouldn't it? >> >> It might, it might not. It depends on what your definition of >> "adequate" entails and which scenarios you are talking about. The >> requirements rejected by the IETF during the Media Security >> Requirements drafting arguably provide a proof case against this >> assertion. >> > Well, making DTLS-SRTP more adequate for 3GPP/TISPAN scenarios (excluding > lawful interception) without making it weaker would be a good thing - better > now? > >> -- >> Dean >> > _______________________________________________ > 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 _______________________________________________ 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
