Dean Willis wrote:
On Dec 8, 2008, at 11:10 AM, Jiri Kuthan wrote:
I think DERIVE is a viable approach for spoofing protection and I
haven't found
a convincing argument that would counter that really.
We agree that a negative-DERIVE test means nothing.
Yes.
Therefore, DERIVE
provides no spoofing protection.
What it does do is potentially provide some assurance of non-spoofing.
That's a very different thing.
In short, the default condition for an astute user should be "The caller
ID may or may not be valid". With negative-DERIVE, this doesn't change.
With positive-DERIVE, the user should think "This caller-ID works for a
return routability check. It is more likely to be valid than if I didn't
have this test, but it might still be faked by a clever badguy".
Yes.
I think the closest match in the history is SPF with largely the same
properties. It can't guarantee incoming traffic is evil (someone just
doesn't advertise SPF for his domain, or uses "mobile MTAs"), it can't
guarantee anything if there are clever badguys (who do DNS attacks too),
and still it effectively helps to reduce traffic with spoofed From.
In fact, after we have deployed SPF for our domain, we have seen a dramatic
increase of spoofed-From-emails with our domain name, that were declined.
Otherwise said: Unknown, Claims-to-be, and Can-be-reached-now-at are the
three possible states produced by DERIVE.
Now, how astute do you think your hypothetical grandmother is likely to be?
At the best, we can get three states to such a user: no ID, not trusted,
and trusted to relatively high level. Those aren't the same three states
that come out of DERIVE. So is it useful to your grandmother, or just
confusing?
I think this is a user-interface/policy thing. On my cell phone I typically
have two profiles, in one of them the phone rings for whitelisted callers,
in the other for all but blacklisted/anonymous callers.
-jiri
--
Dean
_______________________________________________
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
