Re: [stir] SHAKEN but not STIRred means 666 can cause collateral damage

[Paul Kyzivat <[e-mail]>]

On 11/16/16 8:14 PM, Brian Rosen wrote:
> I’ve sent this to stir, even though it has not been decided where the 666 draft will land, and SHAKEN is not even in the IETF.
>
> The original idea of stir is that the credential used to sign is granted as a result of delegation of the telephone number.  When used as envisioned, a valid signature will (mostly) guarantee that the calling party number has not been spoofed.  If we then implement 666, which is a mechanism to create a black list, then numbers reported as spam come from the actual TN they were placed with, or the signature wouldn’t be valid and we get what we want.
>
> SHAKEN doesn’t do that.  It doesn’t check the TN, it only states that the service provider who signed it is willing to say something about the call.  It has a very desirable capability to lead authorities to the source of spoofed calls.  It will very clearly help us cut down on spoofed calls.
>
> However, when used with 666, SHAKEN has the problem that spoofing is still allowed - it’s just that we can better trace it to its source.  But if a user reports SPAM with a SHAKEN signed claim, the spoofed TN is marked as a spam source.  That means the legitimate owner of the TN may have trouble placing calls.  666 creates collateral damage.

This is an example of the point I have been trying to make, about the 
*meaning* of the code.

The meaning of a code used by STIR is different from the meaning of a 
code used with a cert that is actually tied to the calling number.

And this can mean that a button used to the user to signal spam may vary.

All this needs to be carefully aligned.

	Thanks,
	Paul