On Jul 2, 2008, at 10:18 AM, Paul Kyzivat (pkyzivat) wrote:
Cullen Jennings wrote:
> What about changing
>
>>> it may be less confusing to simply identify the call
>>> as encrypted but to an unknown peer.
>
> to
>
> it may be less confusing to simply identify the call as encrypted
but to
> an unknown peer or to identify the call as insecure and show only
the
> 17005551008 portion of the peers identity.
>
> I'm not sure if that is better or worse but it seems to be one of
the
> few way we have to address the issue Paul raised.
If we had a way to indicate that the identity is untrusted in the
display to the user, that might be acceptable.
BUT, we have a world full of devices that don't have an established
way
to indicate that. So when the call ends up going to one of them, there
remains the choice of displaying the (untrusted) number with no
disclaimers, or not displaying it.
The PSTN world has the same issue. Their choice has typically been to
display it. That may have been justified once, when the phone network
was relatively closed and those with the ability to forge their
identity
were few. Its no longer true, for a variety of reasons. And we are
making it increasingly less true.
Perhaps we just have to accept the fact that entirely untrusted
callerids will be displayed with no indication that they are suspect.
But that then devalues doing anything secure, since the users won't be
able to tell the difference.
Paul
True enough but consider that we are providing a service here far
beyond anything the PSTN offers. My PSTN phone has no way of
displaying if the caller id is secure or not - that is because the
PSTN does not offer security caller-id in any sense of the why we are
using secure here. The PSTN does not have a way of telling me no one
is sitting outside my house with a but-set and listening to my call
because the PSTN simply is not capable of offering that service.
We all know that it is trivial to spoof caller-id on the PSTN, and it
is trivial to do on path "taps" to listen in on a POTS call. The user
interface of POTS devices was not designed in any way to able to
indicate that this a call was not "secure" in this way because it was
never "secure" against these and more importantly, whatever level of
"secure' it was, it was about the same for all calls so there was no
need for an variant indication of level of security. Now in SIP, we
have some calls that are "secure" in this way and some that are not -
we need some user interface to indicate that. I'm not surprised that
the user interfaces designed for the PSTN are not capable of
indicating this - I see no way around that.
So this leads us to why I think Dean's proposal is the right path
forward. It gets us to go publish and complete the best approach we
know how to deal with this problem now while clearly indicating the
limitations of this approach when trying to use the PSTN or VoIP
systems that closely emulate the PSTN in addressing architecture,
transitive trust architectures, and user interfaces. I mostly agree
with the points you are making, I just think that the ideal solution
of security beyond what the PSTN was deigned for and 100% backwards
compatibility with the PSTN is impossible and this approach is well
worth publishing because it does provide real solutions for a
significant number of deployment models.
Cullen <in my individual contributor role>
_______________________________________________
Sip mailing list https://www.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
