Ted - inline...
Ted Hardie wrote:
At 10:50 AM -0500 11/8/07, Paul Kyzivat wrote:
Dean Willis wrote:
[snip]
We're at a decision point here -- do we follow RFC 1984 to the fullest extent
and design a secure protocol that will have limited applicability, or do we
design a protocol with broader applicability that has explicitly negotiated key
sharing?
I don't want to see sip relegated to specialty applications and excluded from
most common usage.
Having the key disclosure explicit to the UAs seems a better. I guess one might
ask why a UA would ever agree to disclose its keys, but the answer clearly is
that it might do so if it has no other option that allows making the call.
You mention below the "lock icon" problem, but that is a subset of the larger
mental model question. How is the user who has no choices but:
1) no call
2) a call for which it must divulge keys
to distinguish between that condition and "The security set-up for this call has failed.
Do you wish to continue the call anyway?" From at least one perspective, the
security set-up for the call has failed if the keys have been forced from the
user;
they no longer have any assurance as to the confidentiality of the call.
I strongly believe that the UI revelation of the key sharing would be minimal or
elided; in your scenario, at least, all carrier calls would have this marker as
a base state. Any warning that common must be expected to be ignored, and
a good UI designer is simply going to get it out of the attention field of the
user.
In other words, this mechanism will likely be invoked with no attention from
the user, with the result that the security characteristics of the call will be
fundamentally different from the users' expectations.
I agree with you that the UI for this is of critical importance for any
of it to mean anything. That in fact is why I keep returning to the
"lock icon" issue.
Its a difficult issue here because while it is critical, UIs are
typically outside the scope that IETF deals with.
If the UI designs end up not displaying this information, or displaying
it in such a way that it is not noticed, or is incomprehensible, then
you are correct that the enemies of confidentiality will have won.
I can certainly *imagine* ways of building UIs for many devices that
would comparable in effectiveness of the lock icon in browsers. (But not
for *all* devices. Its unlikely that a good solution is possible for a
black phone.)
It may indeed mean that some classes of devices, which are intended for
use only on contexts where LI is universal, won't show an indication. I
don't know that there is anything that can or should be done about that.
Its devices that have the chance to operate with/without LI that can
benefit from an indicator.
So, what are we left with? From my perspective, any work on this would have
to be explicitly done in the context of RFC 1984. That may well mean setting
out a reasoned discussion of why the interoperability of the mechanism justifies
the work here. If I hear you right, that statement would be something like:
"We judge having a single signaling system to be of such
over-riding importance that the inclusion of an optional system for
the sharing of keys to support LI is justified. We further strongly encourage
the
development and deployment of systems which notify the end user when these
mechanisms have been invoked, as well as the deployment of systems which
do not include this optional mechanism. While these latter systems will fail in
the presence of key demands, they will also serve as the most potent possible
reminder of the prevalence of potential surveillance."
But I think that statement needs to be in public, in a context that engages the
rest of the IETF and Internet community in an open discussion as to whether
need for a single signalling system does over-ride the concerns expressed
in RFC 1984.
I don't pretend to understand the procedural issues here. I'll take your
word for it.
Speaking personally, it does not do so for me. Recent experience has shown
a tendency toward data mining approaches to interception that make me
believe that the inclusion of this mechanism will support the continuation
of an epic invasion of privacy that is loosely targeted, extraordinarily
easy to abuse, and for which over-sight has been minimal and public debate
gagged. Hobbling a mechanism which can maintain privacy in such an
environment is irresponsible. It is also contrary to the expressed wishes of
the IETF, as set forward in a document that was much debated.
I expect that I am philosophically in a position near to yours. 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.
Yes, I understand the problems that this presents, both for interoperability
and the action of lawful intercept. But I believe that forcing a break here
is honestly the better choice for the Internet and for the future of IETF
technologies. If we do not maintain at least one system capable of maintaining
privacy, we are pushing all communications users into a panopticon
future for their personal communications.
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.
And then, either I need one device to talk via carriers and a different
device to talk using IETF means without the carriers, or else I need a
device that supports both protocols. Requiring distinct devices seems
impractical. If a single device supports both protocols, then we are
back to the same UI issue.
But it gets worse. The choice to go over a carrier is often not made by
the initiating device. The tendency will simply be to bury anchor the
media in an SBC at the enterprise/carrier boundary and have the SBC
disclose the key, totally masking the two cases. So this whole
discussion seems moot unless it is possible to verify that you have
negotiated keys with actual device of the person you are talking with,
and not with some intermediary.
Thanks,
Paul
Speaking for me, personally, the costs are too high. If the working group
does decide to move forward here, I will strongly urge early review by
the broader IETF community, as the consequences of this decision are not
light.
My thanks, Paul, for your reasoned statements; please do take my response
to be directed to you personally.
regards,
Ted Hardie
_______________________________________________
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
