I could not disagree more.
The purpose of our work in IETF forums is not to pander to the service providers and the strongarm tactics that the government uses to control them. It is to provide the best possible protocol that enables as many uses as possible. You yourself have always stated that SIP is general and should support a wide variety of uses cases. Why is that different now with security? Our security requirements and implementation MUST include use cases that involve true end-to-end security that does not include the ability for eavesdropping of any kind, let alone LI. To support this, I would point at the applications I am seeing with my employer, since you have focused on the needs of yours. We build military radios. Those radios are moving towards the use of VoIP and want to leverage SIP for many reasons. There are MANY situations in these environments where end-to-end security is an absolute requirement, in many cases, with NSA Type I encryption to boot. If the protocol does not include these capabilities, others will be needed to support these requirements and interoperability will suffer. While we may provide scenarios where LI can be accomplished, we cannot define the protocol in a way that precludes the ability to do end-to-end security. FM -----Original Message----- From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED] Sent: Saturday, November 10, 2007 10:00 AM To: Peterson, Jon Cc: IETF SIP List; Paul Kyzivat; Elwell, John; Dan Wing; Dean Willis Subject: Re: [Sip] media-security-requirements and lawful intercept I wish I could agree that the likelihood of the irrelevancy of our work is tied to its meeting the needs of end users. Unfortunately, I think the reality is more complex than that. Frankly I think the vast majority of end users don't care at all about this problem, and will not likely choose one provider over another based on the fact that they provide security that protects against malicious proxies or what have you. Keep in mind that the PSTN provides "security" for voice which is far worse even than what sdescriptions provides. My sense of what users probably want is enough security to make sure that some kid on the wifi hotspot can't pick off their credit card numbers when they call their bank from Starbucks. Any of our existing security solutions provide that. The customers of our protocols are the enterprises and service providers that deploy them. If we deliver protocols that they cannot use, because they do not meet their needs in terms of LI (or other network functions), they'll just use something else that does meet their needs. That solution is likely to be what it already is - mostly sdes, along with the security weaknesses it comes with. And furthermore it won't interoperate since other SP or enterprises will choose MIKEY and we'll be in the same mess we are today. I think our engineering challenge is to provide a solution which gives the maximum security possible in an environment where LI exists - because it will exist, like it or not. Furthermore, that solution has to be relatively cost effective to deploy compared to the alternative. For example, if our solution REQUIRES every single call to be decrypted and re-encrypted, this is going to be way more expensive to the deployers of our protocols than sdescriptions. Also keep in mind that its not just voice - but video (ideally hi-def) that is coming down the road, which will make that decrypt/re-encrypt function even more expensive. So why would they choose this new protocol over sdescriptions? sdes will be cheaper to deploy, it will provide security good enough to meet the user's needs, and they can deal with interop via SBCs on the boundary. If we want to do better than that, we better provide an alternative that is more palatable. Thanks, Jonathan R. Peterson, Jon wrote: >> I would prefer a world where all the communications were e2e >> encrypted with no possibility of interception, in spite of the >> class of problems that enables. >> >> But I think that we are on the losing end of that argument, and >> that doing nothing about it is comparable to the ietf history of >> doing nothing about NAT. Better the evil we understand than the one >> that evolves without us. > > If our work here becomes irrelevant, it will be because it doesn't do > what end users want, not because we've been insufficiently obsequious > to the tyrant-of-the-month. Carriers, however broadly the definition > of that term may be creeping in some principalities, have certain > obligations which are not at all intrinsic to the operation of a > protocol like SIP, and we cannot assume that SIP's fate is determined > by its success in that arena alone. > >> Suppose we refused to bend here. Then the carriers that are subject >> to LI will either switch to a non-standard variant of our protocols >> that supports the key access, or will use some entirely different >> protocol. > > As has been already pointed out in this thread, RFC4474 (and any > larger security architecture relying on it) invests the domain > responsible for your AoR with significant trust and responsibility. > That domain can insert men-in-the-middle willy-nilly. This seemed > architecturally reasonable because you need to trust them anyway, for > example, to route calls to you and so on; the sorts of entities to > whom LI requirements apply would tend to be the operators of such > domains, incidentally. The truly paranoid can of course operate their > own domains, personally administer every device, and as such need > only trust themselves to make use of RFC4474. This casts the problem > exactly how it should be, I think - as an administrative problem. How > you deploy and use these tools determines who you need to trust and > where there are potential avenues for adversaries to interfere with > your security. > > Any attempt to cast this as an engineering problem, something that > can be fixed or broken at a protocol level, is in my opinion > misguided. > > Speaking more specifically to R24, my opinion is that a SIP user > should be able to ascertain whether or not a certain set of security > features have been invoked. If those features have been invoked, then > the user might draw the conclusion that it is unlikely, barring some > breakthrough in higher mathematics, that someone is able to listen in > on their conversation. This is entirely orthogonal to whether or not > someone might be intercepting and recording ciphertext media > (something the user cannot hope to ascertain), nor whether or not his > administrative domain has been compromised (also something the user > probably cannot ascertain, even if he runs his own server in a sealed > bunker in Montana, given the potential capabilities of adversaries) > and his keys plundered. The protocol, and consequently the end user, > cannot hope to be privy those lapses. As such it's hard for me to see > what the problem is with R24. > > If, of course, that set of security features cannot be invoked, the > user might draw the conclusion that it is quite likely that someone > is listening in on his conversation, and R24-types might find that > worrisome. But it is no more likely that the baleful eye of > surveillance is scrutinizing the user in this case, really. Inability > to invoke those features cannot be said to inform the user that this > interaction is "subject to lawful interception" or whatever. Lack of > the support for the security features is a much more likely culprit. > > So, my question is, what's the engineering problem? > > Jon Peterson NeuStar, Inc. > > > _______________________________________________ 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 _______________________________________________ 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
