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

Chris Wendt <> Thu, 17 November 2016 07:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8E961295C2 for <>; Wed, 16 Nov 2016 23:59:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zq6KfWITvSql for <>; Wed, 16 Nov 2016 23:59:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD69D12948C for <>; Wed, 16 Nov 2016 23:59:21 -0800 (PST)
Received: by with SMTP id i88so47985297pfk.2 for <>; Wed, 16 Nov 2016 23:59:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uoETb9Jlg9ooUDAWJO7AiSP6sANeAQuJplt9MzlV72c=; b=ie8j7qbMZdu2BZiqS0aqi6UlZaspa6xIuBENPup02FrJZU4YVdiWsw5egk75zthgHd MaHaDUkNm+Ez+LAn4/W3S2AaowuCctkF18JAf4cqXYaP50/0+oW0Q/L9xoCmV4Fq5Ric InGObrw/I7tszmioZyMn7qdLzCMqghUGbNu8yn0FcvyEPioSgK51X0b7N9BC8GkuBqwn m9OW+/hVElhZ1MBXsj3s2848peTo1d+eUUMGkwCON+evWM009Nl5LnDYmOLyRP0zhVc2 No4vd3SC13VwJIL6xTjJWvWxLOyeVFeh6iTRTDs7MaONCv/aMDGyoT5Vs9LK3Wt0tNTR B7Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uoETb9Jlg9ooUDAWJO7AiSP6sANeAQuJplt9MzlV72c=; b=EZK7kEutF466ObwmdR8MqesAlj3PzreSiQhTGOs3gf26hruaC/ByiruxnT+8jip2Sy uoM5nU+MqZExlVZGXyHgzFVzGHQfIdGpIODF5yX4f94CIQXeMoZq6iUcEcXbbM/+wSAk M41i739KBeXoBzDhO+2rtcNhumb6bP+GlIKXW4L1XOVxVwh/KtHjhMJIzqBXpFou0BZH Zvj+pa9ULIRAWvu4qTvaBuog/jC5MNdDi3B0+JfRTBxj8GRqBmNw6T9U8qnAtWIS+WC5 8OLxzPhIAZd/P8Fk7uID6Tspi+qGeCUbtaTjyow7kG/7PNtsT34gC0Hz09uaIRy6YCzK jlCg==
X-Gm-Message-State: ABUngvfltT0Pza8bM05IaYLsaPyWTEqDufVKBzj5HIAnPstuwILFMkYGAJoK/uyGPT0tiA==
X-Received: by with SMTP id p22mr4816530pgd.21.1479369561283; Wed, 16 Nov 2016 23:59:21 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g82sm4032340pfb.43.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 23:59:20 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Chris Wendt <>
In-Reply-To: <>
Date: Thu, 17 Nov 2016 16:59:17 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Brian Rosen <>
X-Mailer: Apple Mail (2.3251)
Archived-At: <>
Cc: IETF STIR Mail List <>
Subject: Re: [stir] SHAKEN but not STIRred means 666 can cause collateral damage
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Nov 2016 07:59:23 -0000

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.


> On Nov 17, 2016, at 10:34 AM, Brian Rosen <> wrote:
> 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 <> 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.
>> Brian
> _______________________________________________
> stir mailing list