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

From: Brian Rosen <[email-masked]>
Date: Thu, 17 Nov 2016 10:14:46 +0900

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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 17 Nov 2016 10:34:17 +0900

Ah, I have over-reached.  SHAKEN has a number of possible claims.  The “highest” of those is roughly equivalent to what original stir proposed to do.  The net effect should be that 666 on that claim should not cause damage. On the “lesser” claims, it could.

Brian

> On Nov 17, 2016, at 10:14 AM, Brian Rosen <[email-masked]> wrote:
>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 17 Nov 2016 16:59:17 +0900

Hi Brian,

With 666, other than in the case of as an input into analytics systems, I don’t believe SHAKEN’s attestations are related, i don’t believe STIR signatures are related either, at least not directly.

My understanding, the intent is a user sends back a 666 to provider and says she believes there is some illegitimate or there is just an unwanted call going on, independent of whether the call was verified or not by STIR or SHAKEN at any attestation level.
The thing would be how the 666 is interpreted by the provider with or without any signature, with the implication that without a signature or with different levels of SHAKEN attestation, service providers must understand that the number may have been spoofed and where the call came from may not be easily traceable. Similarly, as discussed, providers should take into account whether the call was answered or not to determine how “real” the 666 response was toward any user-specific filtering or influencing any more global call analytics. This is the fuzzy reality we are in for a while, until every call is VoIP and is signed end-to-end and what SHAKEN is trying to address in a “best we can do” way until that becomes the case given the realities of a mixed VoIP/SS7 telephone system and an environment where spoofing of any number is an allowed practice.

In addition, the system in general should assume that humans are not perfect and may either mistakenly, or just for vengeance on their ex-boyfriend, or whatever reason send 666 back.  The application level handling of 666 needs to account for or potentially have a way to reset this on a per customer basis.  More globally, from an analytics or aggregation of complaints point of view, if you were to shut-down a number more globally based on a single 666, i don’t think you are implementing things correctly.

I don’t believe there is any intent to fully dictate the application behavior here rather than provide a tool for end users to inject a response code feedback about a call, anything beyond that, from a real-world implementation point of view will have some art in getting things right particularly in the next many years.

-Chris

> On Nov 17, 2016, at 10:34 AM, Brian Rosen <[email-masked]> wrote:
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Nov 2016 17:27:01 +0900

[as SIPCORE chair]

On 11/17/16 10:14, Brian Rosen wrote:
> I’ve sent this to stir, even though it has not been decided where the 666 draft will land

My understanding coming out of DISPATCH is that 666 is appropriate for 
SIPCORE, assuming the new charter is approved by the IESG. I expect the 
proposed charter changes to be uncontroversial.

Based on the foregoing, we (the SIPCORE chairs) think it would be 
appropriate to hold general discussion of both of the
draft-schulzrinne-dispatch-callinfo-spam and 
draft-schulzrinne-dispatch-status-unwanted documents on the SIPCORE list.

I've copied DISPATCH and SIPCORE on this message, and set followups to 
SIPCORE.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Nov 2016 11:20:01 -0500

> 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…

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