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.
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.
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.
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.
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
