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
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip