Re: [stir] The Canadian Regulator has issued a Notice of Consultation on robocalls spoofing STIR/SHAKEN

Tony Rutkowski <tony@yaanatech.co.uk> Fri, 03 February 2017 20:00 UTC

Return-Path: <tony@yaanatech.co.uk>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E231712987F; Fri, 3 Feb 2017 12:00:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffMhpkjFN-fY; Fri, 3 Feb 2017 12:00:05 -0800 (PST)
Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666A7129872; Fri, 3 Feb 2017 12:00:05 -0800 (PST)
Received: from [192.168.1.51] (pool-70-106-242-209.clppva.fios.verizon.net [70.106.242.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id 3CDDA540231; Fri, 3 Feb 2017 20:00:03 +0000 (GMT)
References: <7F3DCD21-1085-4961-82D7-CE12DB308305@shockey.us> <a9417cde-33d4-3da2-ad2a-5b83bd81701f@yaanatech.co.uk> <74394dc8-5a61-cb8f-eb9d-98b499256326@dcrocker.net> <5fbc40d2-51f5-7073-f99a-488cd53f8fce@yaanatech.co.uk> <974c2333-aef5-1c93-744c-58dbaaa20ca9@dcrocker.net>
To: dcrocker@bbiw.net, "stir@ietf.org" <stir@ietf.org>, sipcore@ietf.org
From: Tony Rutkowski <tony@yaanatech.co.uk>
Organization: Yaana Ltd
Message-ID: <286e60eb-baa3-c4ec-6c32-43e217713310@yaanatech.co.uk>
Date: Fri, 03 Feb 2017 15:00:01 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <974c2333-aef5-1c93-744c-58dbaaa20ca9@dcrocker.net>
Content-Type: multipart/alternative; boundary="------------371AFB04B62C0F5BDF896CB7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/c9bSn-dyEh8gFzlVMrtFCWcugJU>
Subject: Re: [stir] The Canadian Regulator has issued a Notice of Consultation on robocalls spoofing STIR/SHAKEN
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: tony@yaanatech.co.uk
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2017 20:00:07 -0000

It may be well understood at some level,
albeit not widely used.  Scaling its use globally
has a chance of between zero and none.
Mr. Google can point you to all the other
solutions proffered out there by other bodies
and national administrations.

So prior to 7 Nov 2016, it had some marginal chance
of having US uptake with a FCC forcing function.
Or at least it sounded good for FCC PR purposes.
Today, in the brave new world in Washington,
it seems just a matter of time it gets formally
flushed along with NetNeutrality, Title II jurisdiction,
etc.  It just doesn't fit the new political paradigm.

Blockchain solutions for dealing with authentication
requirements such as call spoofing are fast ascending
and in the long term far more attractive.  So since
there is now more time to play with, why not shift
to an alternative mechanism that's more contemporary
and with better technical, operational, and political
attributes.   As Bobby Dylan reminded us, you don't
need a weatherman here.

tony


On 2017-02-03 2:39 PM, Dave Crocker wrote:
> Given how many years STIR/Shaken have taken -- and that's for 
> well-understood technology with lots of field experience -- you are 
> suggesting the process start over?
>
> What are the incremental benefits that will accrue from waiting 
> another 5-8 years to deploy this alternative mechanism?
>
> d/