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

Brian Rosen <> Thu, 17 November 2016 01:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D29B1295FB for <>; Wed, 16 Nov 2016 17:34:33 -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 WlIeJjuuC2QH for <>; Wed, 16 Nov 2016 17:34:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59C081296E3 for <>; Wed, 16 Nov 2016 17:34:24 -0800 (PST)
Received: by with SMTP id q130so200118659qke.1 for <>; Wed, 16 Nov 2016 17:34:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=RlxjXhkLxU2LWXBhDHf4olmtkv9kqhzq6i+WTuReNEs=; b=h9sxkebhyDQ5QSa8ImPNbH/JKJ/HEkTcfKc+gGwLOepoLvcIJF4Hng0skdKYVuVB2S b8CfZfJ1BDXtJGIuwxVHEfyEoPDKjpw0t/+a80QW1XmpIPhru/11Y0W/Fg/oDCGrS7i+ XwqYBH/AOIa5tpx0QB2+REExqoEOGKGfkcDIFQdMkdJ8+DsFcU9R9Tu5Wzcht+5/n92l /eUo6PVhbEeQYxr5SU6FKjV7mIwH5Lzw80LtsO1EshAOlNK/oHR9dWM2/+A33B5SuerG osdqVV+hZNwCX68kwW6dDss1TG1YgwxfN8GWfA4Kp51JzMUAXndfODTq0PZuaPsxWH6j SLFA==
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 :content-transfer-encoding:message-id:references:to; bh=RlxjXhkLxU2LWXBhDHf4olmtkv9kqhzq6i+WTuReNEs=; b=aJpFvwsufrk3BCCPnY7QxU8htPKAA8/z+xrJLZBPIjWWplkjrMnfe2k7WRoR3Dgg/T miqkKD3M73zvQTR3vJ4nbufEpoyUe7aJNAszdCjbkU/pUqqgUWcQO3NcyjG0l4T8YIdr CGQMuCysdp1rp7OlqfT4yCMaqoxjZh+toWtRjP6O4vRUfMLjMqr4mhp68R0kGNhlPuH6 KHg+546c2Yszs+EIcWdrlZ9okXGTnPvUvnPFYSKz2pJ2QqRtPij2qXfEs3dbV4L+20Lb bRPvhA8SDwOoVyL8kqv3TOFM0I6Rt8WETPsyv6eAz5uZ/nxgPZLv9qFbYiFFMiiu6tm4 WIEw==
X-Gm-Message-State: AKaTC03ht3Cdpvoo7K6fQNQGnMJPmqQAskFCJ2Mgk9lMI8A2dLUBAW3DMbjz2cEf+b0SvA==
X-Received: by with SMTP id i1mr607089qkd.219.1479346463160; Wed, 16 Nov 2016 17:34:23 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id z7sm341610qkz.7.2016. for <> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Nov 2016 17:34:21 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen <>
In-Reply-To: <>
Date: Thu, 17 Nov 2016 10:34:17 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: IETF STIR Mail List <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
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 01:34:33 -0000

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.


> 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