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
