Scott Lawrence wrote:
On Mon, 2008-12-08 at 15:49 +0100, Jiri Kuthan wrote:
Elwell, John wrote:
[JRE] The number of negatives will diminish, true, but it will never
approach zero, because there will always be negative cases arising from
forking, call forwarding, problematic B2BUAs, etc..
indeed.
So it is a question
whether it will get sufficiently close to zero that the odd false
negative can safely be ignored. I am rather doubtful.
The question remains: why would like to worry about the negative case
when we know it has zero information value?? I cannot conceive anyone
would like to use such non-information and I don't see the point in
studying it then.
I'll turn that question around: what do you think this really achieves
for the ordinary non-technical phone user?
* Sometimes the phone has an indicator that the caller-id has been
verified.
* Sometimes the phone fails to have that indicator, but
regardless, the caller-id may be correct.
The draft does not debate policies, it debates reverse-verification and
that's
really the way the IETF protocols have been built. What you are
suggesting is
a good example but I believe the policies are likely to be more complex.
I think
of scoring, like with Email, that tries to create a balance among all of the
pieces of information that's known about a call. DERIVE is one such. The
positive
DERIVE test increases the score to somewhere close to 100%, the negative
test does
not make it any worse.
I believe that the false-negatives in the latter greatly diminish the
value of the former, because you still have to answer the phone to find
out if it is who it claims to be.
I don't think you have to. Most modern telephones give you a choice of how
you deal with different sorts of calls. I frequently turn on "allow trusted
numbers only" and the rest goes to voicemail. In the default mode for less
busy situations, I choose only strange (anonymous and blacklisted) calls
to go there.
The point is really we cannot devise the policies for the users, but we
owe them
tools upon which they will be able to build up their policies. "trusted
numbers
only" is a useful mode, but not entirely if it is too easy to take
someone else's
From URI.
Further - what part of a caller-id does a phone display? Given:
From: "Scott Lawrence" <[EMAIL PROTECTED]>
what do you suppose a phone will display? For most phones I use today,
it will either be "Scott Lawrence" or "scott", and in any event most
won't have enough characters for a long address. These display
limitations and ambiguities mean that an attacker can trivially create a
return-routable address that will very likely be displayed in the same
way as some other address, so even the positive case can be spoofed as
far as the human user is concerned.
Even then DERIVE is going to be very useful.
Let's consider terminal adapters for a while as these devices really cannot
display much information. (for native SIP phones I would recommend
purchasing
ones with large displays and proper information displayed on it).
If annoying "[EMAIL PROTECTED]" calls a DERIVE callee, and
DERIVE
test is succesful, the DERIVE callee can safely put the caller on a
blacklist.
(e.g., by pressing ###) When next call from the same caller comes, it goes
directly to voicemail.
The real point is: DERIVE increases trust but does not define policies.
-jiri
_______________________________________________
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
