Re: scope of derive

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