Re: [stir] I-D Action: draft-ietf-stir-certificates-13.txt

Tony Rutkowski <> Thu, 30 March 2017 12:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4A991296A3 for <>; Thu, 30 Mar 2017 05:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9STINfDuYKNC for <>; Thu, 30 Mar 2017 05:37:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 71C4312954A for <>; Thu, 30 Mar 2017 05:37:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 58FED1FC; Thu, 30 Mar 2017 12:37:03 +0000 (UTC)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id 6DF3558090; Thu, 30 Mar 2017 12:37:02 +0000 (UTC)
References: <> <> <>
To: Russ Housley <>
Cc: IETF STIR Mail List <>, "Zhao, Houlin" <>, "" <>, "Yang, Xiaoya" <>
From: Tony Rutkowski <>
Organization: Yaana Technologies LLC
Message-ID: <>
Date: Thu, 30 Mar 2017 08:37:01 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------9FF0FEE50FCC2074FF549BC8"
Archived-At: <>
Subject: Re: [stir] I-D Action: draft-ietf-stir-certificates-13.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Mar 2017 12:37:05 -0000

For consideration at today's IETF stir meeting.  I understand
that Mr. Dolmatov is at the meeting representing the ITU-T.


The internet draft specification 
being considered here represents the IETF at its worst. In a foolhardy 
attempt to pander to an intractable FCC political problem, it hijacks a 
well-established ITU role and IPR that it seeks to impose as a “tech 
fix.” To boot, even after three years and 13 revisions, it remains 
unsuitable technically and operationally.

Indeed, the STIR group’s charter casts the misguided objective as a 
lamentation <>. It opines 
that if only all the world's telephone number allocating authorities 
issued digital certificates along with the numbers to the service 
providers receiving them, that were then used to authenticate and route 
traffic to end users, spoofed calls would end, robocalls would be 
mitigated, and the world would be a better place. It is a great 
altruistic academic idea that may play as techno-babble in alt-truth 
Washington, but it isn't even feasible except in highly controlled local 

Furthermore, the telephone number system, the provider identifier 
system, the means of allocation, and the establishment of authority are 
within the remit of the ITU and its Member States. The provisions are 
well established in international, regional, and domestic law and 
standards. Registration authorities exist to implement those 
provisions.It is also all their IPR.  The IETF cannot just take what it 
wishes and publish some new scheme it believes is a fix to the world's 
techno-social ills.

What has been cobbled together here is the technological equivalent of a 
Frankenstein creation with the TN Lists by Reference scheme in the 
draft, id-ad-stirTNList, nothing more than an amusing “wish list.”The 
actual “authoritative” references for telephone numbers and service 
providers and the related bindings that exist under ITU provisions are 
simply ignored.

Lastly, there are potential adverse consequences in addition to all of 
the above concerns. There are collateral vulnerabilities and impacts to 
other telephony infrastructure requirements that are far outside the 
narrow technical remit and competence of the IETF.There are also adverse 
consequences for the IETF itself.This will not play well within the ITU 
and its Member States which are being collectively hijacked. Indeed, the 
IETF as an Art. 50/CV231 member of ITU-T, has an obligation to 
collaborate with them when the ITU has similar work ensuing there. It 
may not even play well at industry venues like the CA/B Forum which if 
this kind of scheme were to go forward, could have been outsourced by 
the ITU-T there.And then there is the culpability of the IETF leadership 
if potential litigation were to ensue when a provider’s traffic gets 
blocked using this specification.

Any one of these factors should provide a basis for rejecting this 
Internet Draft.