> 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
