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

From: [email-masked]
Date: Mon, 27 Mar 2017 14:59:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Telephone Identity Revisited of the IETF.

        Title           : Secure Telephone Identity Credentials: Certificates
        Authors         : Jon Peterson
                          Sean Turner
	Filename        : draft-ietf-stir-certificates-13.txt
	Pages           : 20
	Date            : 2017-03-27

Abstract:
   In order to prevent the impersonation of telephone numbers on the
   Internet, some kind of credential system needs to exist that
   cryptographically asserts authority over telephone numbers.  This
   document describes the use of certificates in establishing authority
   over telephone numbers, as a component of a broader architecture for
   managing telephone numbers as identities in protocols like SIP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-stir-certificates-13
https://datatracker.ietf.org/doc/html/draft-ietf-stir-certificates-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 28 Mar 2017 10:01:54 -0400

This draft is getting better.  However inquiring minds
would raise some substantive concerns about the construct
of authority over telephone numbers.

Perhaps the most significant one is the failure to cite
E.164 and related international standards as authoritative -
even though the purpose of the ID is "establishing authority
over telephone numbers."   Similarly, the chain of authority
described in section 5 is not accurate.  The identifiers are
those of the ITU and its Members pursuant to treaty
provisions, and then delegated to those Members (or in
a few cases to provider registrants directly) who in turn
delegate the administration to some entity, e.g., the NANPA.

For the U.S., the State Dept delegates the authority to the FCC
which in turn delegates it to NANPA.  Indeed, the U.S. Court of
Appeals decision a few days ago, is especially relevant here,
as it established the authority of the Commission to enable
E.164 numbers being allocated directly to VoIP providers.  See

https://www.cadc.uscourts.gov/internet/opinions.nsf/30E3C0768DB6D78C852580ED004F9935/$file/15-1497-1667619.pdf

See also, https://apps.fcc.gov/edocs_public/attachmatch/FCC-15-70A1_Rcd.pdf

On the other side of the "authority" binding, it is also
ICCs (ITU Carrier Codes) pursuant to M.1400 that are
the identifiers.  Here also in the U.S., the authority is
the U.S. State Dept which allocates it to the FCC which
in turn allocates it to NECA.  NECA is directed by the
FCC to use ATIS-0300251.  (The spec itself is not
authoritative.  It is simply informative for expressing
an identifier applicable for the U.S.)

As presently constructed, this draft seems to create its
own scheme for establishing and expressing authority
for E.164 numbers that is contrary to well established
legal and regulatory requirements domestically, regionally,
and internationally - creating its own Service Provider
Code out of thin air.  It also gives the appearance that
the IETF here is acting unilaterally as some kind of job
shop for a one-off local U.S. implementation rather
than acting as an international body.  Perhaps the ITU's
TSB and Study Group 2 can be helpful here.

--tony

On 27-Mar-17 5:59 PM, [email-masked] wrote:
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 28 Mar 2017 16:46:15 -0400

Further to the status of this ID and the need
for further work and collaboration:

1) ITU-T SG2 - which is meeting beginning
tomorrow - actually has two active directly
related work items.  One is a set of use
cases related to Service Provider Identifiers
and the other is an actual draft for them,
designated E.spn, Recommendation for
the management and assignment of
Global SPNs.  This has been ongoing work
there since 2010, and the work items
have remained open.

2) It is not apparent how IETF under its
working arrangements and Art. 50 ITU-T
membership could simply proceed here
in developing specifications and taking
on secretariat activities that are already
proceeding in that venue, or act without
collaborating with them.

3) Because ATIS has relinquished its ITU-T
membership, it can no longer be regarded
as having an ITU-T related role.
https://www.itu.int/online/mm/scripts/gensel11?_orgname=ATIS

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 29 Mar 2017 13:20:02 -0400

Hi all,

In addition to all the major infirmities
of this draft, it's worth noting:

1. The current version of X.509 is 10/2016

2. The current version of X.520 is 10/2016

3. (88) is already registered to id-mod-mudURLExtn2016

4. Thanks to my ASN.1 maven colleague Mike Hammer
who identified a number of issues.  Might be worth gracing
the module with the ASN.1 godfather Olivier Dubuisson
- especially as his colleague is Philippe Fouquart who
is still the designated SG2 editor for the SPN work item.

There are a significant number of communities and
compliance obligations affected by this draft in addition
to the US Robocall PR effort.

--tony

> TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
>
> TNEntry ::= CHOICE {
> 	spc [0] ServiceProviderCodeList,
> 	range [1] TelephoneNumberRange,
> 	one E164Number
> 	}
>
> MH>>> Is this a choice of 2 or 3 items?
>               Seems you can't enumerate item number [2]:  one E164Number.
>
> ServiceProviderCodeList ::= SEQUENCE SIZE (1..3) OF IA5String
>
> TelephoneNumberRange ::= SEQUENCE {
> 	start E164Number,
> 	count INTEGER
> 	}
>
> MH>>> What is the difference between:
> 	Range = TelephoneNumber Range, where
> 		Start is an E164Number, and
> 		Count = 1
>       and
> 	One = E164Number?
>       Two alternate codes means more complex coding.
>
> E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*"))
>
> MH>>>	E164 numbers can be composed only of "0123456789", no?
> 	So, the use of # and * are currently undefined in this ID.
> 	I would assume that:
> 		# would be an ending digit indicating the end of a shorter than 15 digit
> number.
> 		* would be an ending digit wild-card meaning any phone numbers with
> preceding leading digits.
> 	However, that would render the meaning of "One" ambiguous, and
> 		That would provide another way to do Range, which may complicate code.
> 	Also, what would it mean if the # or * appeared at the beginning or middle of
> a digit string?

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 Mar 2017 13:54:05 -0400

This update resolves the concerns that I previously raised.

One nit in Section 8:  s/may included/may be included/

Russ

> On Mar 27, 2017, at 5:59 PM, [email-masked] wrote:
> 
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 Mar 2017 14:38:05 -0400

>              Seems you can't enumerate item number [2]:  one E164Number.

There are 3 items in the CHOICE (spc, range, and one)  The first two are SEQUENCE, so an explicit tag is needed to aid the decoder. The third item is an IA5String.

>      Two alternate codes means more complex coding.

The IA5String shows the stat of a block of phone numbers, and the count says the number of consecutive telephone numbers. It would be better to require count to be greater than 1.

I suggest:

   count INTEGER (2..MAX)

> 	Also, what would it mean if the # or * appeared at the beginning or middle of

The WG already had a discussion on the list about whether to include # and *.  I believe this represents the outcome of that discussion.

Russ

---

From: Michael Hammer <[email-masked]>
Date: Wed, 29 Mar 2017 20:24:08 +0000

Third try.

Outlook and signed messages doesn't work.

________________________________

Michael Hammer

[email-masked]<mailto:[email-masked]>

+1 408 202 9291

(c) 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality notice. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

From: Michael Hammer
Sent: Wednesday, March 29, 2017 4:21 PM
To: [email-masked]' <[email-masked]>; Tony Rutkowski <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: RE: [stir] I-D Action: draft-ietf-stir-certificates-13.txt

Russ,

Sorry, not good enough.

First, it is incredibly bad form to redefine a well-known defined parameter from another SDO at a whim.  That just leads to confusion in the industry.  If you want to define something else, call it something else.

Second, to include extra characters with no definition of how they are to be used will lead to interoperability problems.

That is plain bad.

What do I do if I receive a string:  1#201*555*12324 ?

Lastly, this is a draft, so discussion is not over.

If something is broken, would be good idea to fix it.

________________________________

Michael Hammer

[email-masked]<mailto:[email-masked]>

+1 408 202 9291

(c) 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality notice. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

From: stir [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, March 29, 2017 2:38 PM
To: Tony Rutkowski <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] I-D Action: draft-ietf-stir-certificates-13.txt

Tony:

   TNEntry ::= CHOICE {

   I suggest:

      count INTEGER (2..MAX)

   Russ

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 30 Mar 2017 08:37:01 -0400

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

--tony

The internet draft specification 
<https://datatracker.ietf.org/doc/html/draft-ietf-stir-certificates> 
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 <https://datatracker.ietf.org/wg/stir/charter/>. 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 
environments.

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.