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

[Brian Rosen <[e-mail]>]

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.

Brian