Subject: [stir] My Editorial Suggestions on RFC4474bis

From: "David Frankel" <[email-masked]>
Date: Sun, 21 Aug 2016 10:17:23 -0700

Since my last notes, I've gotten some constructive feedback here and
privately. Now, hoping to also be constructive, I want to volunteer some
comments about specific content in the 4474bis document.

I'll preface this as follows: My interest is in how, and to what extent, the
proposed functionality will address abuse of the public telephone network. 

By "public telephone network" I mean that evolving set of networks and
technologies which permit any party to make a "telephone call" to any other
party, from and to anywhere on the globe, using conventional telephone
number addressing and involving either conventional (circa 1970, perhaps?)
telephones, or something emulating such an instrument (mobile phone, smart
phone, web phone, IP phone, etc.). If we could start over today, we'd no
doubt design the system completely differently, but with an installed base
of perhaps six or seven billion endpoints and associated addresses, and
still growing, it seems likely that this network is still some distance from
retirement.

By "abuse" I mean (1) the use of the network to defraud, steal from, or deny
service to a call recipient; (2) placing of programmatic unsolicited
marketing-related and similar calls that, intentionally or not, annoy or
harass a call recipient. I note that the prevalence of these abuses
compromises the beneficial uses of the network by promoting suboptimal
behaviors on the part of telephone subscribers (refusing to answer any call
for fear it is an abusive call; sending all or most calls to voice-mail or
CAPTCHA to avoid abusive calls; etc.); this impedes the flow and utility of
good (non-abusive) calls.

Rather than parsing the document section by section, I've structured my
comments categorically since several of my suggestions touch in multiple
places.

OBJECTIVES / PURPOSE

I want to reiterate some text from the SIP WG charter because I need to
confirm that we are all on the same page regarding our goals. It states:
"Since it has become fairly easy to present an incorrect source telephone
number, a growing set of problems have emerged over the last decade. As with
email, the claimed source identity of a SIP request is not verified,
permitting unauthorized use of the source identity as part of deceptive and
coercive activities, such as robocalling (bulk unsolicited commercial
communications), vishing (voicemail hacking, and impersonating banks) and
swatting (impersonating callers to emergency services to stimulate
unwarranted large scale law enforcement deployments). In addition, use of an
incorrect source telephone number facilitates wire fraud or can lead to a
return call at premium rates." (Paragraph 1) And "As its priority mechanism
work item, the working group will specify a SIP header-based mechanism for
verification that the originator of a SIP session is authorized to use the
claimed source telephone number, where the session is established with SIP
end to end." (Paragraph 3)

That strikes me as a noble undertaking and I'm reading the document in that
context.

4474bis states at 3. Background: "Per [RFC7340], problems such as
robocalling, voicemail hacking, and swatting are enabled by an attacker's
ability to impersonate someone else." I don't agree that RFC7340 states that
these abuses are "enabled" by the "ability to impersonate someone else."
First, "enabled" implies that if there were no such ability, then these
attacks would be "disabled" and it isn't that cut and dried. Impersonation
"facilitates" (or as the charter states, is "part of") deceptive and
coercive activities. Second, RFC7340 is explicit that both impersonation and
obfuscation (or obscuration) contribute to the problems. At Page 4, it says:
"In general, number spoofing is used in two ways: impersonation and
anonymization." 

When explaining the context and how 4474bis fits, caution and precision are
important. Here's my attempt at replacing the first paragraph of section 3:

"Per [RFC7340], attackers often take advantage of the current ease with
which calling telephone numbers can be spoofed, and the singular reliance
some call recipients place on that value. This allows abuse, for example, of
a voicemail service that compares the identity of the caller to a whitelist
before determining whether it should allow the caller access to recorded
messages. Another example: an Internet telephone application that displays
the calling party number (and/or an associated name retrieved from a local
database) of a caller, which a human may review to make a policy decision
before answering a call. In both of these cases, attackers might attempt to
circumvent these authorization policies through impersonation. If the
calling party number could be verified - that is, if the receiving person or
application could know with reasonable certainty that the calling number was
not spoofed - then additional screening could be bypassed. The voicemail
service could give the caller direct access to the mailbox without demanding
a password; the Internet telephone application could tell the human that
less stringent verbal verification procedures can be applied because we have
confidence that the caller is who they claim to be." 

Obviously any well-designed use of current calling number information should
recognize how readily this can be spoofed and should not operate without
some additional form of verification.

It is incorrect to say "The mechanism described in this document provides a
strong identity system for detecting attempted impersonation in SIP
requests." What is strong about this mechanism is detecting that that the
caller is authorized to use the claimed phone number. Since most calls, for
the foreseeable future, will lack the Identity header, the mechanism
provides no real means of detecting attempted impersonation. Whether a call
without an Identity header is or is not an impersonation cannot be
determined. Certainly a call with an Identity header that does not verify
can be assumed to be either an impersonation or a technical or operational
failure, but it seems unlikely that impersonators would go to the trouble of
sending an Identity header that will not verify.

There is some related discussion currently in section 12.5, but I believe
this needs to be brought forward and made more explicit because the
"transition" will not be quick.

We should also be careful not to assert that this mechanism universally
protects the CALLER NAME that is presented for many public network calls. If
the NAME is being retrieved from a LOCAL DATABASE (such as the user's
contact list in a mobile phone) there is less concern. But if the name is
retrieved, as it so often currently is in real-world deployments, from some
network database populated by any number of different contributors
(including abusers), this mechanism provides no vehicle to prevent a caller
with a verified NUMBER from linking that number to a NAME like "Card
Services" or "FBI" or "Frankel David" when they are in fact none of the
above. The existing text says "the calling party number (and/or Caller-ID)
of a caller" but "Caller-ID" is not defined and is ambiguous.

Section 12.6 discusses signing of the Display Name; the text indicates this
is out of scope but offers some thoughts. I think Display Name generally is
out of scope (RFC7340 states: "This effort does not consider how the display
name of the caller might be validated.") so 4474bis shouldn't indicate what
action "should" or "could" be taken with respect to that field. Note that
the Display Name field is only applicable for end-to-end SIP calls. I
suggest replacing 12.6 paragraph two as follows:

"Many current telephony deployments use the calling number to derive an
alphanumeric Calling Name for display to the called party. Given the nature
of many of these deployments, even a verified calling number could result in
the display of a falsified or impersonated name. The verified calling number
will be most useful when the name is derived from a local database (such as
a mobile phone contact list) maintained and trusted by the call recipient."

We still need a discussion of the other half of the problem (per RFC7340),
which is ANONYMIZATION of the calling party. What I see today in 4474bis
addresses forms such as "[email-masked]" where the caller explicitly
declares anonymity. This is really related to privacy, which is why 4474bis
has it in a section with that title. 

For abusive calls, the calling party generally achieves true anonymity
either by spoofing somebody else's phone number (often, in fact, just using
random numbers, or using a number similar to, but distinct from, the called
number), or by using one or more numbers that they have acquired but which
are challenging to identify (because when called, the number is not answered
or yields only a vague voice-mail, and/or because the service provider
responsible for the number doesn't know or won't reveal who the actual
customer is).

The 3. Background section of 4474bis should include some mention of the
anonymity problem, just as it discusses impersonation. I suggest: "Today,
because it is easy to originate calls with any value in the From header,
abusive callers can populate the field with random telephone numbers.
Abusive callers (and their enabling service providers) are likely to be the
last adopters of the Identity header. Until the Identity header becomes
prevalent across the universe of calls (and that will take some time, since
it initially will only apply to end-to-end SIP calls, which are a tiny
minority), the anonymity problem will remain because the abusive calls will
be lost in the sea of normal (but unauthenticated) calls. Additionally, when
a significant number of calls generally ARE authenticated, abusive callers
may seek to obtain telephone numbers which they can authenticate, but which
still are ambiguous as to their ownership. It will be incumbent upon service
providers and the regimes in which they operate to prevent such abuses
(through means outside the scope of this document). If it is easy and cheap
for abusers to obtain quantities of telephone numbers and associated
credentials without providing true identity information linked to those
numbers, they will be able to remain anonymous even with valid Identity
headers in their calls."

As an aside, there are about six billion valid numbers in the North American
(+1) Numbering Plan. There are currently probably on the order of one
billion of those assigned to end-users. Of the remaining five billion, some
fraction are allocated to service providers already (but unassigned to
end-users); the rest are currently unallocated. Abusive callers have, and
will probably continue to have, a variety of options for finding numbers
they can use to keep themselves anonymous until all the loopholes are
finally closed.

DOMAIN vs. NUMBER AUTHENTICATION

The Charter of the STIR Working Group states:

"The STIR working group will specify Internet-based mechanisms that allow
verification of the calling party's authorization to use a particular
telephone number for an incoming call." (First Sentence)

"The work of this group is limited to developing a solution for telephone
numbers. Expansion of the authorization mechanism to identities using the
user@domain or other name forms is out of scope." (Fifth Paragraph)

Given this, 4474bis should not contain, to the extent that it does,
references to authenticating From headers containing [email-masked] or
[email-masked]. (These appear repeatedly in Sections 1, 4, 6, and 7.) There
is also text about "signing for a domain." 

This is explicitly outside of scope, and it distracts from the stated
purpose of the WG. If nothing else, I think we want the document to read
very clearly, to the greatest extent possible, how the spec is used to
achieve the goal of authenticating telephone numbers.

I suggest that other than to briefly reiterate that it is out of scope, all
the references to authentication of domains be removed, and that all
examples be restricted to that which is in scope (phone numbers).

Certainly there is value in what has been (speculatively) documented
regarding signing for a domain. This material could simply be archived for
retrieval later, when we are ready to tackle that.

If there is insistence that it be included here (despite the mandate in the
charter that "expansion...using user@domain...is out of scope"), then it
should be collected and placed in an appendix outside the primary flow of
the document. I do realize the value of being forward-looking. At the same
time, there is such urgency in getting STIR deployed for telephone numbers
that I don't think we can afford the distraction.

I must admit that I personally have had a terrible time reconciling how this
all actually functions for telephone numbers. "Domain" appears 81 times in
the document and I can't tell which, if any, of those occurrences is
relevant to the telephone number use case.

ERRATA

In going through the document I encountered a handful of typos. If you
search for each of the text snippets below I think the issue will be
apparent.

those JSON object in a manner following PASSporT

implementation the authentication service at an

which contains a JSON representations of

and add a corresponding an Identity header to the request

is OPTIONAL baseline PASSporT objects in SIP as

authentication service creates a PASSporT that uses ["object" is missing]

verification service performs the procedures above on each [should be
"below"]

verifier MUST inspect any optional "ppt" parameter appearing the

Step 1, is understood), the verifier follows the procedures ["supported"
instead of "understood"]

prospect that a verification services could receive

The verification of an Identity header does not entail [suggest "The
successful verification"]

encoding of the header and claim component of

this it conveys any canonical telephone number formats

canonicalization of the numbers and compare them ["numbers" plural?]

unless they have some more other implementation-specific way

role for a range of telephone and a user agent belonging to Alice

included in a PASSporT object in, for example, an "uri" claim.

correspond to any field of the SIP request, but then the optional

legitimate request for one user is cut-and-pasted into a request

consult some sort of directory that indications

David Frankel

ZipDXR LLC

Monte Sereno, CA USA

Tel: 1-800-FRANKEL (1-800-372-6535)

 <http://www.zipdx.info/features/> Watch Our Video!

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 21 Aug 2016 16:57:15 -0400

Hi David,

What you posit is not really a definition of what
is regarded (or defined in law) as the public
telephone network.    The common first industry
specifications were developed at the CCIF preparatory
conference in 1923, and the first international
legal provisions in the Paris Conference in 1925.

The equivalent of the distributed global domain name
system was developed after WWII, and specified today
in Rec. ITU-T E.164.  Use of those numbers and the
associated routing is the subject of multiple provisions
found in treaty instruments and national legislation, as
well as what constitutes public telephone service.  A
recent Technical Report adopted at ETSI details eleven
different categories of "compliance obligations" associated
with the service.

It is unlikely to be retired in part because of the trust
levels associated with the legal constructs and provisions
that result in relatively high trust levels - which is of
course what threads through stir and being led by
Martin and many other telecommunication industry
colleagues.

best,
tony

On 2016-08-21 1:17 PM, David Frankel wrote:
> By “public telephone network” I mean that evolving set of networks and 
> technologies which permit any party to make a “telephone call” to any 
> other party, from and to anywhere on the globe, using conventional 
> telephone number addressing and involving either conventional (circa 
> 1970, perhaps?) telephones, or something emulating such an instrument 
> (mobile phone, smart phone, web phone, IP phone, etc.). If we could 
> start over today, we’d no doubt design the system completely 
> differently, but with an installed base of perhaps six or seven 
> billion endpoints and associated addresses, and still growing, it 
> seems likely that this network is still some distance from retirement.

---

From: Richard Shockey <[email-masked]>
Date: Sun, 21 Aug 2016 18:23:41 -0400

Dave once again, thank you for your deeply thoughtful comments.  

You are clearly taking out of your busy schedule as a C level executive to think hard and fast about what is going on and more important you have skin in the game because you actually are delivering a real product and real service. You are part of this industry. You like ATT, Comcast, Sprint and VZ and others are going to have to live with some of this construct so your views are clearly important.

Let me try and set some things now in context.

Right now a process is being put in motion that has multiple parts, multiple actors and the IETF is only one of them. In the US right not the principal actor is the FCC Strike Force.  US National Policy will be driven out of that body.  Protocol decisions will be determined in part out of the IETF and this WG but there are multiple actors.  Implementation issues may derive from joint activity from the ATIS SIP Forum TF and other ATIS bodies but highly critical issues may derive from the proposed work in 3GPP.  They are IMS after all.  I have been convinced from the beginning of this process that unless we give the consumer adequate signaling as to the results of the validation process we are not going to succeed. 

Attached is my Work in progress on what I think User Agent Validation Display should maybe look like. 

You ann assume BTW that this activity is being monitored by other NRA’s. 

My principal worry at this point is setting unrealistic expectations to the FCC and other NRA’s  on what SDO can do and how the vendor community can implement solutions in a reasonable time frame.  As I have privately briefed the usual suspects there is not a “Silver Bullet” nor is there a “Magic Wand” by which we as technical professionals can make this scourge go away overnight. After all this process is now 4 years running for some of us.  Anyone familiar with the modern phone networks knows there is a IP transition in process and considerations of security, reliability is utmost in the minds of service providers and our regulators.

This is a multi-layered approach over time. First deal with the NANP E.164 layered issues between SP’s that can be controlled.  That IMHO is where we can achieve first order success.  Let’s postulate Sprint trusts Comcast and Comcast trusts Sprint.  That is what the JWT signed object can deliver right now. How certificate  credentials are created and passed among US carriers are NOT THE BUSINESS OF THE IETF. That is high policy.

How Sprint gets the validation data to its UA is where 3GPP comes into play.   How that data gets to IP PBX’s or hosted UA is something I think the SIP Forum can take up at the appropriate time.  How this plays out in other naming and addressing schemes like WEBRTC  is for another time and place and Jon and his folks will tell us when they are ready.   

We are no longer in the business of ending world hunger. We have a specific challenge and a task laid out by Chairman Wheeler and Randall Stephenson and IMHO they have done exactly the right thing. 

BTW I also believe there are some unique business opportunities here.  Clearly there are some unique models for validation analytics here that no one wants to actually talk about since that may involve real money J 

From: stir <[email-masked]> on behalf of David Frankel <[email-masked]>
Organization: ZipDX LLC
Date: Sunday, August 21, 2016 at 1:17 PM
To: <[email-masked]>
Subject: [stir] My Editorial Suggestions on RFC4474bis

Since my last notes, I’ve gotten some constructive feedback here and privately. Now, hoping to also be constructive, I want to volunteer some comments about specific content in the 4474bis document.

I’ll preface this as follows: My interest is in how, and to what extent, the proposed functionality will address abuse of the public telephone network. 

By “public telephone network” I mean that evolving set of networks and technologies which permit any party to make a “telephone call” to any other party, from and to anywhere on the globe, using conventional telephone number addressing and involving either conventional (circa 1970, perhaps?) telephones, or something emulating such an instrument (mobile phone, smart phone, web phone, IP phone, etc.). If we could start over today, we’d no doubt design the system completely differently, but with an installed base of perhaps six or seven billion endpoints and associated addresses, and still growing, it seems likely that this network is still some distance from retirement.

By “abuse” I mean (1) the use of the network to defraud, steal from, or deny service to a call recipient; (2) placing of programmatic unsolicited marketing-related and similar calls that, intentionally or not, annoy or harass a call recipient. I note that the prevalence of these abuses compromises the beneficial uses of the network by promoting suboptimal behaviors on the part of telephone subscribers (refusing to answer any call for fear it is an abusive call; sending all or most calls to voice-mail or CAPTCHA to avoid abusive calls; etc.); this impedes the flow and utility of good (non-abusive) calls.

Rather than parsing the document section by section, I’ve structured my comments categorically since several of my suggestions touch in multiple places.

OBJECTIVES / PURPOSE

I want to reiterate some text from the SIP WG charter because I need to confirm that we are all on the same page regarding our goals. It states: “Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or can lead to a return call at premium rates.” (Paragraph 1) And “As its priority mechanism work item, the working group will specify a SIP header-based mechanism for verification that the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end.” (Paragraph 3)

That strikes me as a noble undertaking and I’m reading the document in that context.

4474bis states at 3. Background: “Per [RFC7340], problems such as robocalling, voicemail hacking, and swatting are enabled by an attacker's ability to impersonate someone else.” I don’t agree that RFC7340 states that these abuses are “enabled” by the “ability to impersonate someone else.” First, “enabled” implies that if there were no such ability, then these attacks would be “disabled” and it isn’t that cut and dried. Impersonation “facilitates” (or as the charter states, is “part of”) deceptive and coercive activities. Second, RFC7340 is explicit that both impersonation and obfuscation (or obscuration) contribute to the problems. At Page 4, it says: “In general, number spoofing is used in two ways: impersonation and anonymization.” 

When explaining the context and how 4474bis fits, caution and precision are important. Here’s my attempt at replacing the first paragraph of section 3:

“Per [RFC7340], attackers often take advantage of the current ease with which calling telephone numbers can be spoofed, and the singular reliance some call recipients place on that value. This allows abuse, for example, of a voicemail service that compares the identity of the caller to a whitelist before determining whether it should allow the caller access to recorded messages. Another example: an Internet telephone application that displays the calling party number (and/or an associated name retrieved from a local database) of a caller, which a human may review to make a policy decision before answering a call. In both of these cases, attackers might attempt to circumvent these authorization policies through impersonation. If the calling party number could be verified – that is, if the receiving person or application could know with reasonable certainty that the calling number was not spoofed – then additional screening could be bypassed. The voicemail service could give the caller direct access to the mailbox without demanding a password; the Internet telephone application could tell the human that less stringent verbal verification procedures can be applied because we have confidence that the caller is who they claim to be.” 

Obviously any well-designed use of current calling number information should recognize how readily this can be spoofed and should not operate without some additional form of verification.

It is incorrect to say “The mechanism described in this document provides a strong identity system for detecting attempted impersonation in SIP requests.” What is strong about this mechanism is detecting that that the caller is authorized to use the claimed phone number. Since most calls, for the foreseeable future, will lack the Identity header, the mechanism provides no real means of detecting attempted impersonation. Whether a call without an Identity header is or is not an impersonation cannot be determined. Certainly a call with an Identity header that does not verify can be assumed to be either an impersonation or a technical or operational failure, but it seems unlikely that impersonators would go to the trouble of sending an Identity header that will not verify.

There is some related discussion currently in section 12.5, but I believe this needs to be brought forward and made more explicit because the “transition” will not be quick.

We should also be careful not to assert that this mechanism universally protects the CALLER NAME that is presented for many public network calls. If the NAME is being retrieved from a LOCAL DATABASE (such as the user’s contact list in a mobile phone) there is less concern. But if the name is retrieved, as it so often currently is in real-world deployments, from some network database populated by any number of different contributors (including abusers), this mechanism provides no vehicle to prevent a caller with a verified NUMBER from linking that number to a NAME like “Card Services” or “FBI” or “Frankel David” when they are in fact none of the above. The existing text says “the calling party number (and/or Caller-ID) of a caller” but “Caller-ID” is not defined and is ambiguous.

Section 12.6 discusses signing of the Display Name; the text indicates this is out of scope but offers some thoughts. I think Display Name generally is out of scope (RFC7340 states: “This effort does not consider how the display name of the caller might be validated.”) so 4474bis shouldn’t indicate what action “should” or “could” be taken with respect to that field. Note that the Display Name field is only applicable for end-to-end SIP calls. I suggest replacing 12.6 paragraph two as follows:

“Many current telephony deployments use the calling number to derive an alphanumeric Calling Name for display to the called party. Given the nature of many of these deployments, even a verified calling number could result in the display of a falsified or impersonated name. The verified calling number will be most useful when the name is derived from a local database (such as a mobile phone contact list) maintained and trusted by the call recipient.”

We still need a discussion of the other half of the problem (per RFC7340), which is ANONYMIZATION of the calling party. What I see today in 4474bis addresses forms such as “[email-masked]” where the caller explicitly declares anonymity. This is really related to privacy, which is why 4474bis has it in a section with that title. 

For abusive calls, the calling party generally achieves true anonymity either by spoofing somebody else’s phone number (often, in fact, just using random numbers, or using a number similar to, but distinct from, the called number), or by using one or more numbers that they have acquired but which are challenging to identify (because when called, the number is not answered or yields only a vague voice-mail, and/or because the service provider responsible for the number doesn’t know or won’t reveal who the actual customer is).

The 3. Background section of 4474bis should include some mention of the anonymity problem, just as it discusses impersonation. I suggest: “Today, because it is easy to originate calls with any value in the From header, abusive callers can populate the field with random telephone numbers. Abusive callers (and their enabling service providers) are likely to be the last adopters of the Identity header. Until the Identity header becomes prevalent across the universe of calls (and that will take some time, since it initially will only apply to end-to-end SIP calls, which are a tiny minority), the anonymity problem will remain because the abusive calls will be lost in the sea of normal (but unauthenticated) calls. Additionally, when a significant number of calls generally ARE authenticated, abusive callers may seek to obtain telephone numbers which they can authenticate, but which still are ambiguous as to their ownership. It will be incumbent upon service providers and the regimes in which they operate to prevent such abuses (through means outside the scope of this document). If it is easy and cheap for abusers to obtain quantities of telephone numbers and associated credentials without providing true identity information linked to those numbers, they will be able to remain anonymous even with valid Identity headers in their calls.”

As an aside, there are about six billion valid numbers in the North American (+1) Numbering Plan. There are currently probably on the order of one billion of those assigned to end-users. Of the remaining five billion, some fraction are allocated to service providers already (but unassigned to end-users); the rest are currently unallocated. Abusive callers have, and will probably continue to have, a variety of options for finding numbers they can use to keep themselves anonymous until all the loopholes are finally closed.

“The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call.” (First Sentence)

“The work of this group is limited to developing a solution for telephone numbers. Expansion of the authorization mechanism to identities using the user@domain or other name forms is out of scope.” (Fifth Paragraph)

Given this, 4474bis should not contain, to the extent that it does, references to authenticating From headers containing [email-masked] or [email-masked]. (These appear repeatedly in Sections 1, 4, 6, and 7.) There is also text about “signing for a domain.” 

This is explicitly outside of scope, and it distracts from the stated purpose of the WG. If nothing else, I think we want the document to read very clearly, to the greatest extent possible, how the spec is used to achieve the goal of authenticating telephone numbers.

I suggest that other than to briefly reiterate that it is out of scope, all the references to authentication of domains be removed, and that all examples be restricted to that which is in scope (phone numbers).

Certainly there is value in what has been (speculatively) documented regarding signing for a domain. This material could simply be archived for retrieval later, when we are ready to tackle that.

If there is insistence that it be included here (despite the mandate in the charter that “expansion...using user@domain...is out of scope”), then it should be collected and placed in an appendix outside the primary flow of the document. I do realize the value of being forward-looking. At the same time, there is such urgency in getting STIR deployed for telephone numbers that I don’t think we can afford the distraction.

I must admit that I personally have had a terrible time reconciling how this all actually functions for telephone numbers. “Domain” appears 81 times in the document and I can’t tell which, if any, of those occurrences is relevant to the telephone number use case.

ERRATA

In going through the document I encountered a handful of typos. If you search for each of the text snippets below I think the issue will be apparent.

authentication service creates a PASSporT that uses [“object” is missing]

verification service performs the procedures above on each [should be “below”]

Step 1, is understood), the verifier follows the procedures [“supported” instead of “understood”]

The verification of an Identity header does not entail [suggest “The successful verification”]

canonicalization of the numbers and compare them [“numbers” plural?]

 

David Frankel

ZipDX® LLC

Monte Sereno, CA USA

Watch Our Video!

_______________________________________________ stir mailing list [email-masked] https://www.ietf.org/mailman/listinfo/stir

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Aug 2016 10:04:09 +0000

Hi,

I don’t want to tell the draft authors how to handle text change suggestions, but one option would be to use GitHub, where people can make pull requests with the suggested changes. Probably would make life a little easier for everyone involved :)

Regards,

Christer

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday 22 August 2016 at 01:23
To: David Frankel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] My Editorial Suggestions on RFC4474bis

BTW I also believe there are some unique business opportunities here.  Clearly there are some unique models for validation analytics here that no one wants to actually talk about since that may involve real money :)

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of David Frankel <[email-masked]<mailto:[email-masked]>>
Organization: ZipDX LLC
Date: Sunday, August 21, 2016 at 1:17 PM
To: <[email-masked]<mailto:[email-masked]>>
Subject: [stir] My Editorial Suggestions on RFC4474bis

OBJECTIVES / PURPOSE

We still need a discussion of the other half of the problem (per RFC7340), which is ANONYMIZATION of the calling party. What I see today in 4474bis addresses forms such as “[email-masked]<mailto:“[email-masked]>” where the caller explicitly declares anonymity. This is really related to privacy, which is why 4474bis has it in a section with that title.

Given this, 4474bis should not contain, to the extent that it does, references to authenticating From headers containing [email-masked]<mailto:[email-masked]> or [email-masked]<mailto:[email-masked]>. (These appear repeatedly in Sections 1, 4, 6, and 7.) There is also text about “signing for a domain.”

If there is insistence that it be included here (despite the mandate in the charter that “expansion...using user@domain...is<mailto:user@domain...is> out of scope”), then it should be collected and placed in an appendix outside the primary flow of the document. I do realize the value of being forward-looking. At the same time, there is such urgency in getting STIR deployed for telephone numbers that I don’t think we can afford the distraction.

ERRATA

David Frankel
ZipDX® LLC
Monte Sereno, CA USA
Tel: 1-800-FRANKEL (1-800-372-6535)
Watch Our Video!<http://www.zipdx.info/features/>

_______________________________________________ stir mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/stir

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Aug 2016 10:32:31 -0400

Given that this isn’t SIP Forum/ATIS/3GPP, there are two IETF related items I would like to comment on:

One is that I really don’t think that a device that can do the kind of intelligent display of the results of the validation can do the validation.  Therefore, I don’t think it’s worthwhile to have some signaling path that states that the carrier validated and “trust me, everything is okay”.  Just send the signature.  It might be helpful to have a cert with a stapled OCSP response in the body if there wasn’t one to begin with, which any convenient B2BUA could add.  Having that would be much better in many more circumstances.   Since there is clearly a trust boundary between the network and the user, P-Asserted-Identity should not be passed to the user.

The other thing is that we can get a whole lot of value out of stir when the termination network is POTS.  You dismiss that as not feasible, but it is if the validation is applied at the transit network.
That would cover SIP origination, POTS termination, or even SIP origination. SIP termination with a POTS transit in between.  You need to emphasize that in the IETF work, the originating device or network has to sign, but anyone along the path can validate.  Since interconnection between networks is subject to interconnect agreements, they can stipulate that valid signatures must be present.  As I have noted, this could be phased in by expressing the requirement as a percentage good signed calls by a specified date.

In fact, I believe that if deployment was initially on interconnects, we would get much more bang for our buck than large (trusted) carrier to large (trusted) carrier.

And, one more comment: I think we’re going to get much earlier interoperability testing at SIPit then we can expect from the 3GPP test bed.

Brian

> On Aug 21, 2016, at 6:23 PM, Richard Shockey <[email-masked]> wrote:
> 
> <Shockey Call Validation Display SIPNOC v2 2016.pptx>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Aug 2016 11:01:10 -0400

Brian,

I support almost everything you say below. But I think you accidentally 
got one statement wrong that almost inverts what I think you intended to 
say. And I another smaller comment.

On 8/22/16 10:32 AM, Brian Rosen wrote:
> One is that I really don’t think that a device that can do the kind of intelligent display of the results of the validation can do the validation.

s/don't/do/

> Therefore, I don’t think it’s worthwhile to have some signaling path that states that the carrier validated and “trust me, everything is okay”.  Just send the signature.  It might be helpful to have a cert with a stapled OCSP response in the body if there wasn’t one to begin with, which any convenient B2BUA could add.  Having that would be much better in many more circumstances.

> Since there is clearly a trust boundary between the network and the user, P-Asserted-Identity should not be passed to the user.

I agree with the above statement *if* the caller requested anonymity.

If the caller *did not* request anonymity, then there is no reason to 
strip P-Asserted-Identity. Most likely trust is asymmetric in this case, 
where the carrier doesn't trust the user but the user may have some 
degree of trust in the network. So having the P-Asserted-Identity can be 
of value to the user and discloses nothing that the caller desired to hide.

	Thanks,
	Paul

> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 23 Aug 2016 06:25:14 -0700

David wrote:
> I don't agree that RFC7340 states that these abuses are "enabled" by the "ability to impersonate someone else.

+1 --- I don't read RFC7340 as saying this either, as my earlier comments to this group stated.  Further, I don't believe that RFC7340 is completely accurate.  In my experience, most North American telephony abuse is facilitated by anonymity and accessibility.    In this context anonymity includes identity masking achieved by random impersonation but excludes targeted impersonation such as of the IRS using 800-xxx-1040,  and this combined with accessibility is exemplified by the fact that no government issued ID need be shown to easily obtain low-cost service at a retail store or over the internet.

An anonymous caller proving to terminating networks or their users that the caller has been assigned the calling number doesn't, on its own, do much to change this.  What really helps is having some control over the attackers' ability to (1) obtain service and (2) complete calls.   Knowing a party that can be held accountable that happens to be in a position to mitigate the abuse helps with the first, and reputation-based filters and indications help with the second.

----Who's the Authority?----

A point that may be pondered relates to the ambiguity surrounding the "authority" implied by the charter's use of the word "authorized".

"As its priority mechanism work item, the working group will specify a SIP header-based mechanism for verification that the originator of a SIP session is _authorized_ to use the claimed source telephone number, where the session is established with SIP end to end."

One interpretation is that any signer may be an authority.  An originating telco, in that it can choose (perhaps with guidance from regulators) whether or not to allow a call to be originated, is clearly in a position of authority.  And such a statement of authority has significant meaning to reputation-based filters and displays as well as post-call traceback and mitigation efforts.

Another is interpretation is that the authority must come from proper assignments and/or delegations traceable to the root authority for that type of identity.   This of course has a different meaning.

It seems that the group has been more focused on the latter, but I do not have the history to see how this emerged.  Could someone explain whether and how the latter became the dominant focus?

----Per-TN Certificates----

Signing with per-telephone-number certificates seems to be lacking support for implementation by network operators.  If anyone has a contrary view, please express it.  Per-call queries to verify certificate validity would need to check revocation status, and the infrastructure required to maintain timely revocation status is expensive at the per-TN scale.  If a large service provider needs to check 2,000 peer service provider certs for revocation every 10 minutes (which is somewhere around the reaction time of many spam filters), fine.  But scanning CRLs for every call (to check for a cert with service cancelled or delegation revoked) is burdensome, as is CRL publication.  Yes, optimal implementations can ease the burden, but a substantial burden remains.

So putting all of this together, it seems that the _pressing_ need is for signing by the originating service provider using a key assigned to that service provider, but little more.   There is urgency; both delay in standards approval and additional complexity that slows or inhibits widespread STIR adoption are undesirable.

Regards,

Alex

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 23 Aug 2016 13:46:05 +0000

The a SHAKEN framework supports a pool of certs per carrier, not cert per TN

But it is ok for the RFCs yo have a broader scope for as long as they are delivered on time

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Aug 23, 2016, at 9:40 AM, Alex Bobotek <[email-masked]<mailto:[email-masked]>> wrote:

David wrote:
> I don’t agree that RFC7340 states that these abuses are “enabled” by the “ability to impersonate someone else.

+1 --- I don’t read RFC7340 as saying this either, as my earlier comments to this group stated.  Further, I don’t believe that RFC7340 is completely accurate.  In my experience, most North American telephony abuse is facilitated by anonymity and accessibility.    In this context anonymity includes identity masking achieved by random impersonation but excludes targeted impersonation such as of the IRS using 800-xxx-1040,  and this combined with accessibility is exemplified by the fact that no government issued ID need be shown to easily obtain low-cost service at a retail store or over the internet.

An anonymous caller proving to terminating networks or their users that the caller has been assigned the calling number doesn’t, on its own, do much to change this.  What really helps is having some control over the attackers’ ability to (1) obtain service and (2) complete calls.   Knowing a party that can be held accountable that happens to be in a position to mitigate the abuse helps with the first, and reputation-based filters and indications help with the second.

----Who’s the Authority?----

A point that may be pondered relates to the ambiguity surrounding the “authority” implied by the charter’s use of the word “authorized”.

“As its priority mechanism work item, the working group will specify a SIP header-based mechanism for verification that the originator of a SIP session is _authorized_ to use the claimed source telephone number, where the session is established with SIP end to end.”

----Per-TN Certificates----

Regards,

Alex
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Aug 2016 10:17:26 -0400

The work we have done has always treated the number of TNs per cert to be a variable.  It can be one1 per cert, it can be one per carrier, or anything in between.
The way this works is that a cert is valid for a set of TNs, and that set can change over time.  We provide an operation to ask if a given cert is valid for a given TN, because the list of TNs associated with a cert changes over time due to porting, new delegations in, etc.

It’s pretty tough, but not impossible, for a large carrier to manage one TN per cert.  On the other hand, it’s also tough to handle keys securely when there is one cert per carrier if the carrier has lots of infrastructure that needs to be able to sign.  So the “pool per carrier” idea is pretty reasonable.

Brian

> On Aug 23, 2016, at 9:46 AM, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Cell: +1.609.903.3360 <tel:+1.609.903.3360>
> Email: [email-masked] <mailto:[email-masked]>
>  
> 
> On Aug 23, 2016, at 9:40 AM, Alex Bobotek <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>  
>> David wrote:
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Aug 2016 07:40:25 -0700

> So putting all of this together, it seems that the _pressing_ need is for signing by the originating service provider using a key assigned to that service provider, but little more.   There is urge…

[BA] If we only have signing by the originating service provider, what are the expectations on the provider that come with signing? Is it only that the call originates from an authenticated customer (but not necessarily that the TN is authorized for that customer)?  Or can the provider only sign for TNs they are assigned (or for TNs assigned to that customer)? Trying to understand what claims made in the draft remain for the most likely initial deployment scenario.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 23 Aug 2016 14:50:02 +0000

Alex wrote:
------------------------------------------------------------------
----Who's the Authority?----

It seems that the group has been more focused on the latter, but I do not have the history to see how this emerged.  Could someone explain whether and how the latter became the dominant focus?
------------------------------------------------------------------

My opinion is the focus on the latter, if there is a focus, is a legalistic interpretation.  A number of contributors have pointed to the idea that since carriers transport calls and often delegate or assign Telephone Numbers to their enterprise, government, and consumer customers, carriers should be held liable for calls placed by or terminated for bad actors.

To me that is like holding turnpike operators liable for crimes committed by criminals who've paid for the opportunity to drive on the privately maintained roadways.  Yes, turnpike operators admit criminals to their network, and may have had reason to suspect them, and victims might have wished the turnpike operators had not permitted them access, but one person's protection can be another person's discrimination.

And the ambiguity of knowing, to a legally liable certainty, that a calling number was "authorized" to be used by a call originator can be more or less difficult depending upon the circumstances of the call origination access and delegation of numbering (and signing) authority.

I assume that the fastest possible way to implement call signing and interpretation using STIR technology is by US carriers (because of the intense pressure from the US government because of the intense pressure from US voters).  I also assume some sort of safe harbor guarantees need to be included in recommendations to government law and policy makers to address liability concerns of carriers.

Pierce

From: Alex Bobotek [mailto:[email-masked]]
Sent: August 23, 2016 8:25 AM
To: David Frankel <[email-masked]>; [email-masked]
Subject: Re: [stir] My Editorial Suggestions on RFC4474bis

----Per-TN Certificates----

Regards,

Alex

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Aug 2016 07:49:47 -0700

On 8/23/2016 7:17 AM, Brian Rosen wrote:
> It’s pretty tough, but not impossible, for a large carrier to manage one
> TN per cert.

Where is the operational history that demonstrates meaningful viability 
for use of certs *in this way* and *at this scale*?

I am not aware of any.

In theory, there is no difference between theory and practice...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Aug 2016 11:25:43 -0400

There isn’t any real way to say that a particular service provider is a “good” SP and another one is a “bad” or even “questionable” SP.  The only way to make a claim that means something is “I have a cert that covers the TN that the call claims to be from, and my signature is proof that it came from me, the service provider who was delegated the TN".  If you don’t want the authorities taking action against you, then you probably want to make sure that you delegated that TN to the customer that is sending the call via your service, but the signature doesn’t make that claim.  It claims that you, the service provider, was delegated the TN.

If you, at some point, arrange for the customer to get a cert with your delegation of the TN to him, then he can sign, claiming he was delegated the TN.  

We sometimes use the expression “sign on behalf of the customer”, but that isn’t the claim.  The claim is YOU (the SP) were delegated the number, and it comes from your service.

Brian

> On Aug 23, 2016, at 10:40 AM, Bernard Aboba <[email-masked]> wrote:
> 
> On Aug 23, 2016, at 06:25, Alex Bobotek <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 23 Aug 2016 16:18:10 +0000

Soon, we will be talking about E.164/6 or /7 . /10?  :)

On liability, I assume liability ends when the operator definitively ID's
the organization delegated the TN who is initiating the robo-call.

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 Brian Rosen
Sent: Tuesday, August 23, 2016 10:17 AM
To: DOLLY, MARTIN C <[email-masked]>
Cc: [email-masked]; Alex Bobotek <[email-masked]>; David Frankel
<[email-masked]>
Subject: Re: [stir] My Editorial Suggestions on RFC4474bis

The work we have done has always treated the number of TNs per cert to be a
variable.  It can be one1 per cert, it can be one per carrier, or anything
in between.

The way this works is that a cert is valid for a set of TNs, and that set
can change over time.  We provide an operation to ask if a given cert is
valid for a given TN, because the list of TNs associated with a cert changes
over time due to porting, new delegations in, etc.

It's pretty tough, but not impossible, for a large carrier to manage one TN
per cert.  On the other hand, it's also tough to handle keys securely when
there is one cert per carrier if the carrier has lots of infrastructure that
needs to be able to sign.  So the "pool per carrier" idea is pretty
reasonable.

Brian

On Aug 23, 2016, at 9:46 AM, DOLLY, MARTIN C <[email-masked]
<mailto:[email-masked]> > wrote:

But it is ok for the RFCs yo have a broader scope for as long as they are
delivered on time

Martin C. Dolly

AT&T

Cell:  <tel:+1.609.903.3360> +1.609.903.3360

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

On Aug 23, 2016, at 9:40 AM, Alex Bobotek < <mailto:[email-masked]>
[email-masked]> wrote:

> I don't agree that RFC7340 states that these abuses are "enabled" by the
"ability to impersonate someone else.

+1 --- I don't read RFC7340 as saying this either, as my earlier comments to
this group stated.  Further, I don't believe that RFC7340 is completely
accurate.  In my experience, most North American telephony abuse is
facilitated by anonymity and accessibility.    In this context anonymity
includes identity masking achieved by random impersonation but excludes
targeted impersonation such as of the IRS using 800-xxx-1040,  and this
combined with accessibility is exemplified by the fact that no government
issued ID need be shown to easily obtain low-cost service at a retail store
or over the internet. 

An anonymous caller proving to terminating networks or their users that the
caller has been assigned the calling number doesn't, on its own, do much to
change this.  What really helps is having some control over the attackers'
ability to (1) obtain service and (2) complete calls.   Knowing a party that
can be held accountable that happens to be in a position to mitigate the
abuse helps with the first, and reputation-based filters and indications
help with the second. 

----Who's the Authority?----

A point that may be pondered relates to the ambiguity surrounding the
"authority" implied by the charter's use of the word "authorized". 

"As its priority mechanism work item, the working group will specify a SIP
header-based mechanism for verification that the originator of a SIP session
is _authorized_ to use the claimed source telephone number, where the
session is established with SIP end to end." 

One interpretation is that any signer may be an authority.  An originating
telco, in that it can choose (perhaps with guidance from regulators) whether
or not to allow a call to be originated, is clearly in a position of
authority.  And such a statement of authority has significant meaning to
reputation-based filters and displays as well as post-call traceback and
mitigation efforts. 

Another is interpretation is that the authority must come from proper
assignments and/or delegations traceable to the root authority for that type
of identity.   This of course has a different meaning. 

It seems that the group has been more focused on the latter, but I do not
have the history to see how this emerged.  Could someone explain whether and
how the latter became the dominant focus? 

----Per-TN Certificates----

Signing with per-telephone-number certificates seems to be lacking support
for implementation by network operators.  If anyone has a contrary view,
please express it.  Per-call queries to verify certificate validity would
need to check revocation status, and the infrastructure required to maintain
timely revocation status is expensive at the per-TN scale.  If a large
service provider needs to check 2,000 peer service provider certs for
revocation every 10 minutes (which is somewhere around the reaction time of
many spam filters), fine.  But scanning CRLs for every call (to check for a
cert with service cancelled or delegation revoked) is burdensome, as is CRL
publication.  Yes, optimal implementations can ease the burden, but a
substantial burden remains.  

So putting all of this together, it seems that the _pressing_ need is for
signing by the originating service provider using a key assigned to that
service provider, but little more.   There is urgency; both delay in
standards approval and additional complexity that slows or inhibits
widespread STIR adoption are undesirable. 

Regards,

Alex

_______________________________________________
stir mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/stir>
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/stir>
https://www.ietf.org/mailman/listinfo/stir

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Aug 2016 13:09:57 -0400

Recognizing that we are beyond the IETF’s purview, I would say as long as the SP has someone to hand the hot potato to, then its hands are clean and cool.

And I like E.164/6, but of course it would be decimal digits and not powers of two.

> On Aug 23, 2016, at 12:18 PM, Michael Hammer <[email-masked]> wrote:
> 
> Soon, we will be talking about E.164/6 or /7 … /10?  J
>  
> On liability, I assume liability ends when the operator definitively ID’s the organization delegated the TN who is initiating the robo-call.
>  
> © 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.
>  
> Cc: [email-masked]; Alex Bobotek <[email-masked]>; David Frankel <[email-masked]>
> On Aug 23, 2016, at 9:46 AM, DOLLY, MARTIN C <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Aug 2016 10:36:54 -0700

On 8/23/2016 10:09 AM, Brian Rosen wrote:
> Recognizing that we are beyond the IETF’s purview, I would say as long
> as the SP has someone to hand the hot potato to, then its hands are
> clean and cool.

There is a piece of this that is essential to the IETF work, namely 
sufficient and explicit clarity about usage alternatives to ensure that 
the technical specifications can support them.

Specifying a cert subsystem that relies on a timely and accurate 
revocation list, at the scale and granularity of per-number, would be an 
example of something that has never been done, where the relevant 
history strongly indicates it won't work.

That level of consideration and design choice is very much /inside/ the 
IETF's purview.

d/

-- 

   Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Aug 2016 13:49:06 -0400

Yes, of course you are right.  We specified OCSP for this purpose.

Brian

> On Aug 23, 2016, at 1:36 PM, Dave Crocker <[email-masked]> wrote:
> 
> There is a piece of this that is essential to the IETF work, namely sufficient and explicit clarity about usage alternatives to ensure that the technical specifications can support them.
> 
> Specifying a cert subsystem that relies on a timely and accurate revocation list, at the scale and granularity of per-number, would be an example of something that has never been done, where the relevant history strongly indicates it won't work.
> 
> That level of consideration and design choice is very much /inside/ the IETF's purview.
> 
> d/
> 
> -- 
> 
>  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Aug 2016 10:53:11 -0700

Brian,

I did not choose the example randomly, nor did I generate an artificial 
comment to go along with it.

With your response -- which I expected -- my example moves from theory 
to fact:  So, please provide some documentation about its successful use 
at scale.

d/

-- 

   Dave Crocker

---

From: Michael Hammer <[email-masked]>
Date: Tue, 23 Aug 2016 18:02:05 +0000

Dave,

I am sure the Wright Brothers heard the same statements 
before they ignored those statements and invented the airplane.

That line of logic leads nowhere.

________________________________
Michael Hammer
[email-masked]
+1 408 202 9291

© 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.

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Tuesday, August 23, 2016 1:53 PM
To: Brian Rosen <[email-masked]>
Cc: [email-masked]; [email-masked]; Michael Hammer
<[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [stir] My Editorial Suggestions on RFC4474bis

Brian,

With your response -- which I expected -- my example moves from theory to
fact:  So, please provide some documentation about its successful use at
scale.

d/

On 8/23/2016 10:49 AM, Brian Rosen wrote:
>>> Recognizing that we are beyond the IETF’s purview, I would say as 
>>> long as the SP has someone to hand the hot potato to, then its hands 
>>> are clean and cool.
>>
>>
sufficient and explicit clarity about usage alternatives to ensure that the
technical specifications can support them.
revocation list, at the scale and granularity of per-number, would be an
example of something that has never been done, where the relevant history
strongly indicates it won't work.
IETF's purview.

-- 

   Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Aug 2016 14:20:46 -0400

Scale here, at least initially, is a relatively small number of participants (service providers) with a relatively small number of certs (pool per SP) with a relatively high volume of OCSP queries (one per call, but clearly disbursed to multiple redundant responders).  

What scaling are you worried about?  The protocol?  The database?  The compute load?

I know of at least one DoD deployment, and a couple of cert providers who do better than that.

Brian
> On Aug 23, 2016, at 1:53 PM, Dave Crocker <[email-masked]> wrote:
> 
> Brian,
> 
> I did not choose the example randomly, nor did I generate an artificial comment to go along with it.
> 
> With your response -- which I expected -- my example moves from theory to fact:  So, please provide some documentation about its successful use at scale.
> 
> d/
>

---

From: [email-masked]
Date: Tue, 23 Aug 2016 12:40:41 -0600

Expectations will be determined my national policy (this is fully Title 
II Telecom) and ultimately codified into bi-lateral interconnection 
agreements among providers.

There are already some safe harbor provisions in place at the FCC that 
permits the carrier to block at the direct request of the consumer.   If 
there are clarifications needed then those questions, including 
additional enforcement issues will be outlined by the FCC Strike Force.

As for secondary users of NANP resources we can presume the SP of record 
may issue a credential to the ( OTT provider ) that will have some 
indication of secondary providers identity [ aka a OCN number ]. You can 
bet this will apply to the International Wholesale gateways.

We don't need to specify every corner case.  In fact the IETF should not 
specify ANY policy consideration.

As for the larger issue of distribution of credentials I think you can 
assume that for the first order instantiation those entities with direct 
access to the NANP will have access.  Those non facilities based 
carriers can apply for direct access to the NANP in the usual way at the 
FCC they way Vonage did or work with their business partners. We start 
with circles of trust and build out.

Example of large scale PKI distribution schemes are well documented and 
this is not even large scale.  We are not talking TN level except for 
some very very specific use cases that are outside the scope of these 
drafts.

Its been suggested btw that the certificate draft needs specific 
language indicating that National Regulatory Authorities need to take 
approproiate steps to assert their authority and control over these 
resources surrounding their portions of the E.164 consistent with 
appropriate national laws and regulations.

On 2016-08-23 08:40, Bernard Aboba wrote:
>> So putting all of this together, it seems that the __pressing__ need
>> is for signing by the originating service provider using a key
>> assigned to that service provider, but little more. There is
>> urgency; both delay in standards approval and additional complexity
>> that slows or inhibits widespread STIR adoption are undesirable.
> 
> [BA] If we only have signing by the originating service provider, what
> are the expectations on the provider that come with signing? Is it
> only that the call originates from an authenticated customer (but not
> necessarily that the TN is authorized for that customer)? Or can the
> provider only sign for TNs they are assigned (or for TNs assigned to
> that customer)? Trying to understand what claims made in the draft
> remain for the most likely initial deployment scenario.

---

From: [email-masked]
Date: Tue, 23 Aug 2016 12:41:47 -0600

+1

On 2016-08-23 12:20, Brian Rosen wrote:
> Scale here, at least initially, is a relatively small number of
> participants (service providers) with a relatively small number of
> certs (pool per SP) with a relatively high volume of OCSP queries (one
> per call, but clearly disbursed to multiple redundant responders).
> 
>> to fact:  So, please provide some documentation about its successful 
>> use at scale.
>> 
>> d/
>> 
>>>>> long
>>>> sufficient and explicit clarity about usage alternatives to ensure 
>>>> that the technical specifications can support them.
>>>> 
>>>> revocation list, at the scale and granularity of per-number, would 
>>>> be an example of something that has never been done, where the 
>>>> relevant history strongly indicates it won't work.
>>>>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Aug 2016 20:13:48 -0700

Brian,

On 8/23/2016 11:20 AM, Brian Rosen wrote:
> certs (pool per SP) with a relatively high volume of OCSP queries
> (one per call, but clearly disbursed to multiple redundant
> responders).

So this system is intended for use with only a small number of 
tightly-integrated participants?

But wait, we certainly know that they are expected to be 
/administratively independent/?

So the scale and implied tight integration are not not what I've been 
hearing, where some folk even believe this needs to support verification 
by independent end-user devices.  And your response leaves open the 
question of what is expected for global operations.

Anyhow, what is significant is that no one has bothered to specify and 
gain consensus on the operational targets.  And of course, the larger 
flaw in your response is that we don't use 'initially' as the design 
target when asking about scaling.  (We do use it when talking about 
early adopters, but that's an entirely different topic.)

> What scaling are you worried about?  The protocol?  The database?

None of those.

The task here is for a query service that operates on a global scale 
with perhaps some thousands of /independent/ service providers and 
perhaps billions of (potentially independent) verifiers, based on the 
aggregate of comments people have been making.  (Yes, I believe that is 
a reasonable summary and yes I fully expect folk to challenge the 
summary; that's fine.  Get the goal documented with consensus and people 
won't be pulling out stray targets they find convenient.)

Now, please point out the large number of query services successfully 
deployed on the Internet that conform to that operational target.  The 
only one I know of is the DNS.

And then there the failure of ENUM to perform pretty much exactly the 
query task needed here, albeit returning different information.  Unless 
that difference in what is returned is offered as justifying comfort for 
this new effort -- with an explanation for why -- I remain mystified and 
the lack of concern about the technical and operational details of this 
key functional requirements for STIR.

> I know of at least one DoD deployment, and a couple of cert providers

None of that is relevant to the operational requirements here.

Seriously Brian, is the issue of large-scale, independent administrative 
control that foreign a topic to this working group?

d/

>> With your response -- which I expected -- my example moves from
>> theory to fact:  So, please provide some documentation about its
>> successful use at scale.
>>
>> d/
>>
>>>>> Recognizing that we are beyond the IETF’s purview, I would
>>>>> say as long as the SP has someone to hand the hot potato to,
>>>>> then its hands are clean and cool.
>>>>
>>>>
>>>> There is a piece of this that is essential to the IETF work,
>>>> namely sufficient and explicit clarity about usage alternatives
>>>> to ensure that the technical specifications can support them.
>>>>
>>>> Specifying a cert subsystem that relies on a timely and
>>>> accurate revocation list, at the scale and granularity of
>>>> per-number, would be an example of something that has never
>>>> been done, where the relevant history strongly indicates it
>>>> won't work.
>>>>

-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 24 Aug 2016 07:38:26 +0000

Hi David,

You are correct that the first sentence of Section 3 sort of lumps robocalling, voicemail hacking, and swatting into one bucket, and that "enable" doesn't fit all the contents of that bucket equally well. Voicemail hacking ("News of the World" style) is directly enabled by impersonation, you can't do it without impersonation. I think I might say instead that these practices "commonly leverage" an attacker's ability to impersonate someone else's identity. I think though I'm going to end up removing this text from the spec anyway, and instead slightly amplifying the text in the introduction about RFC7340.

As to whether the mechanism described in the document "provides a strong identity system for detecting attempted impersonation," I'm afraid I can't agree with your reasons for saying that is incorrect. A lack of implementation would not change whether or not the -document- describes such a system. The presence or absence of an Identity header from any given SIP message wouldn't change that either. This is a sentence about a document, not about a deployment.  But again, I think this text will likely be removed for unrelated reasons.

The specification is very careful to say that it does not protect caller name, but it does so by saying that it doesn't protect display-name (the text you indicate in 12.6), which is the way you carry a caller name in SIP. There is no other commentary of any kind about how systems might derive caller name in this specification, and I'd hesitate to introduce some. The text in the second paragraph of 12.6 serves a very different purpose than the paragraph you propose to replace it. I don't see any harm in noting that telephone numbers are sometimes used to derive display names, but I see no justification for having this specification deliver guidance on what sort of name databases consumers should or should not trust.

I think some of your concerns about anonymity demonstrate how we use the term differently in SIP than we might in everyday discourse. If you "achieve true anonymity by spoofing somebody else's phone number (often, in fact, just random numbers)" you are still spoofing a phone number. Your ability to spoof telephone numbers enables that. What it is to claim anonymity in SIP is to not divulge an individual identifier for yourself, usually by using instead some kind of privacy service which sets your identity to something that makes it clear that you want to remain anonymous. Impersonating random telephone numbers is different - it is still impersonating numbers. As the Privacy Considerations state, and state correctly I believe, "None of the relevant attacks, all of which rely on the attacker taking on the identity of a victim or hiding their identity using someone else's identity, are enabled by anonymous identity."

As to the problem of abusive users obtaining telephone numbers "which they can authenticate, but which still are ambiguous as to their ownership," this is noted in the section on "Authorization and Transitional Strategies," as are most of the similar concerns you raise here. We all know, for example, that security vulnerabilities could allow attackers to compromise devices that could make calls which possess totally valid credentials. No one here thinks secure signaling is a silver bullet. However, the barrier to entry for populating a From header field, versus compromising a device, is very different. Similarly, the barrier to entry to acquiring "ambiguous" telephone numbers is surely higher than just putting whatever comes to mind in a From header field. The differences are real; I don't think we're overselling them.

While I do agree that the STIR charter considers "greenfield" SIP URIs out of scope, we long ago made a consensus decision in this working group not to bar that text from rfc4474bis or any other proposals for solutions here. STIR does not require this to solve its immediate threat model. However, as we looked at gatewaying and so on, we quickly saw that there were going to be cases where such identifiers would appear. I don't think it constitutes much of a distraction, and in fact, I'd say the solution would be incomplete without it.

Your nits are appreciated - this text is getting a pretty thorough errata-vetting at this point.

Thanks,

Jon Peterson
Neustar, Inc.

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of David Frankel <[email-masked]<mailto:[email-masked]>>
Organization: ZipDX LLC
Date: Sunday, August 21, 2016 at 10:17 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [stir] My Editorial Suggestions on RFC4474bis

OBJECTIVES / PURPOSE

ERRATA

David Frankel
ZipDX® LLC
Monte Sereno, CA USA

---

From: Brian Rosen <[email-masked]>
Date: Wed, 24 Aug 2016 09:28:06 -0400

The system we envisioned will grow, eventually quite large.  It starts off small, and grows gradually.  That’s an ideal deployment scenario.  It’s not intended have a small number of tightly integrated participants, you made that up.  It starts with a relatively small number of participants, period.

I’m not sure what you mean by “administratively independent”.  Within a country, participants are all regulated by the same regulator, but that’s the only common administration.

We start “small” (the number of TNs, and the number of transactions does not start small) and we grow.  Because we have a working delegation process that we understand, asking that the PKI follow that seems pretty reasonable.  At least some of us want to get to the point where devices generate and check, and since there are working delegation processes that get numbers to devices, we believe we can grow out straightforwardly to that.

There has ALWAYS been some participants who scoff at the notion that we’ll ever get to devices generating and checking, but none have objected to making the system capable of doing that.  I believe we have rough consensus on that point, since it’s been part of the discussions from the beginning.

We do in fact care about being able to start small and grow.  When someone proposes a system that depends on something changing on a large number of independent implementations with a hard cutover, we usually don’t think that’s a good design.  I’m not aware of anyone who believes OCSP doesn’t scale at the levels we’re discussing.  There are enough implementations at sufficient scale to convince me, and others that it’s more than feasible.  This isn’t web PKI, we have root of trust in the regulator and leaves that follow the delegation path.

I don’t see anyone else with your concern here.  I see people agreeing the document language can be improved in several ways.  I believe, as do most every one else who has dug into the details, that we have a workable, deployable, scaleable approach to solving a real problem.  The work group consensus was determined some time ago, the industry has embraced the approach and we have implementors using the documents to build real code.  

Brian

> On Aug 23, 2016, at 11:13 PM, Dave Crocker <[email-masked]> wrote:
> 
> Brian,
> 
> So this system is intended for use with only a small number of tightly-integrated participants?
> 
> But wait, we certainly know that they are expected to be /administratively independent/?
> 
> So the scale and implied tight integration are not not what I've been hearing, where some folk even believe this needs to support verification by independent end-user devices.  And your response leaves open the question of what is expected for global operations.
> 
> Anyhow, what is significant is that no one has bothered to specify and gain consensus on the operational targets.  And of course, the larger flaw in your response is that we don't use 'initially' as the design target when asking about scaling.  (We do use it when talking about early adopters, but that's an entirely different topic.)
> 
> 
> 
> The task here is for a query service that operates on a global scale with perhaps some thousands of /independent/ service providers and perhaps billions of (potentially independent) verifiers, based on the aggregate of comments people have been making.  (Yes, I believe that is a reasonable summary and yes I fully expect folk to challenge the summary; that's fine.  Get the goal documented with consensus and people won't be pulling out stray targets they find convenient.)
> 
> Now, please point out the large number of query services successfully deployed on the Internet that conform to that operational target.  The only one I know of is the DNS.
> 
> And then there the failure of ENUM to perform pretty much exactly the query task needed here, albeit returning different information.  Unless that difference in what is returned is offered as justifying comfort for this new effort -- with an explanation for why -- I remain mystified and the lack of concern about the technical and operational details of this key functional requirements for STIR.
> 
> 
> Seriously Brian, is the issue of large-scale, independent administrative control that foreign a topic to this working group?
> 
> d/
> 
> 
> 
>> Brian
>  bbiw.net <http://bbiw.net/>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Aug 2016 08:38:18 -0700

On 8/24/2016 6:28 AM, Brian Rosen wrote:
> The system we envisioned will grow, eventually quite large.  It starts
> off small, and grows gradually.  That’s an ideal deployment scenario.
>  It’s not intended have a small number of tightly integrated
> participants, you made that up.  It starts with a relatively small
> number of participants, period.

Sigh.  No, Brian, it's the response you offered.  And you offered it in 
response to an explicit question about scaling, without offering any 
other statements about scaling.

Of course I knew it was wrong.  But absent any documentation for the 
target scaling and in the presence of significant variations in implied 
answers, based on postings from different working group participants, I 
thought it important to underscore.

For a number of choices made in the design, there is a long history of 
scaling problems.  So while this latest note from you states a generic 
"quite large", there is no sense of how to achieve it.

> I’m not sure what you mean by “administratively independent”.

That's a rather remarkably statement, within an IETF working group, 
since administrative independence is the essence of what makes almost 
all Internet services different from enterprise services.

>  Within a
> country, participants are all regulated by the same regulator, but
> that’s the only common administration.

First, regulation is not the same as administrative control, unless you 
want to say that all the telephone companies in the US operate under 
uniform administrative control.

Second, regulation varies between countries.

So there is quite a lot of independence for each service provider.

And independent administrative operation imposes its own type of 
operational constraints.

> We start “small” (the number of TNs, and the number of transactions does
> not start small) and we grow.  Because we have a working delegation
> process that we understand, asking that the PKI follow that seems pretty
> reasonable.  At least some of us want to get to the point where devices
> generate and check, and since there are working delegation processes
> that get numbers to devices, we believe we can grow out
> straightforwardly to that.

That's fine.

Where is this working design documented?   Certainly it isn't anywhere 
in the 3 documents up for last call.

> There has ALWAYS been some participants who scoff at the notion that
> we’ll ever get to devices generating and checking, but none have
> objected to making the system capable of doing that.  I believe we have
> rough consensus on that point, since it’s been part of the discussions
> from the beginning.

Where is the working group consensus for that specific design goal? 
 From the postings I've seen, there is an inconsistent sense of this 
goal among participants.

Worse, the target for the query service apears to be non-public access, 
which precludes use by private (independent) user devices.

> We do in fact care about being able to start small and grow.  When
> someone proposes a system that depends on something changing on a large
> number of independent implementations with a hard cutover, we usually
> don’t think that’s a good design.  I’m not aware of anyone who believes
> OCSP doesn’t scale at the levels we’re discussing.  There are enough

OCSP was published 17 years ago.  That permits quite a lot of analysis 
of its production use.

What is its operational history that encourages this faith in its 
ability to scale among many independent operators at a global level?

> implementations at sufficient scale to convince me, and others that it’s
> more than feasible.  This isn’t web PKI, we have root of trust in the
> regulator and leaves that follow the delegation path.

"The"?  You mean "all of the".  There is no one regulator at the top of 
the tree, unless I suppose you intend to have the PKI root be 
administered by the ITU.

And by the way, all of this 'regulator' reference applies only to 
telephony using telephone numbers.  It doesn't apply to telephony using 
non-telephonic URI's.

> I don’t see anyone else with your concern here.

And yet I'm asking only the most basic and well-established questions.

The lack of general concern about the pragmatics for this design, given 
how important and urgent the service, ought to have given folks more 
pause.

I see people agreeing
> the document language can be improved in several ways.  I believe, as do
> most every one else who has dug into the details, that we have a
> workable, deployable, scaleable approach to solving a real problem.  The
> work group consensus was determined some time ago, the industry has
> embraced the approach and we have implementors using the documents to
> build real code.

And yet, Brian, repeating statements of assurance like that does not 
take the place of serious technical and operational assessment.

And what makes such assurances especially striking are the facts that 
the previous effort to create an inter-provider query service based on 
telephone numbers failed, and the proposed service is substantially more 
complex...

d/

-- 

   Dave Crocker

---

From: "David Frankel" <[email-masked]>
Date: Wed, 24 Aug 2016 18:31:35 -0700

Hi Jon -

Thanks for investing your time to respond to my comments. I'll try to step
through each general area briefly.

Regarding some of the text in section 3, Background: thanks for the
modifications.

Regarding caller-name: 

You say: "it doesn't protect display-name (the text you indicate in 12.6),
which is the way you carry a caller name in SIP." My response is: In the
context of what we (or at least I) am calling a "PUBLIC TELEPHONE NETWORK
end-to-end SIP call" you are incorrect or at least not helpful when you say
that display-name "is the way you carry a caller name".

Again, my context is a "phone call" from an endpoint identified with a
telephone number, to a different endpoint with a telephone number, using
telephone-number-based addressing. And I continue to think that is the
PRIMARY focus of this work. In that context, there are several ways of
sourcing a caller-name for display to the end-user, but I believe the most
common are consistent with what I described. At the end of these comments
I've given a detailed example for reference.

In the Working Group charter, I read "the claimed source identity of a SIP
request is [currently] not verified, permitting unauthorized use of the
source identity as part of deceptive and coercive activities.." This is the
general problem that I think the group and the specs are trying to address.
>From an end-user perspective both the number and name that they see are part
of the "source identity". Including some sort of helpful, clarifying comment
about how this particular spec does or does not influence the name, which is
often the more important element in terms of what the user sees and relies
on, strikes me as appropriate.

You say you're happy with section 12.6 and that it serves a different
purpose. Why don't you augment 12.6 then, and make it even more helpful by
serving an additional purpose? My sense is that there is other text
currently included that gives "guidance" on various matters that are perhaps
peripheral to the precise specification but relevant in the context of the
problem statement. 

Regarding anonymization: 

You say: "I think some of your concerns about anonymity demonstrate how we
use the term differently in SIP than we might in everyday discourse." I
introduced my comments by referencing what RFC7340 says about anonymization.
I think I am using the term consistently with that RFC. The fact that "we
use the term differently in SIP" is perhaps worthy of some explanation in
the spec. Addressing anonymization the way it is used in the STIR Problem
Statement (even if it is not "the way we use it in SIP") is also worth some
explanation.

You say: "[T]he barrier to entry to acquiring 'ambiguous' telephone numbers
is surely higher than just putting whatever comes to mind in a From header
field." I don't think we know that (yet). We certainly hope it will be. But
robocallers are adept at leaping at least low hurdles, so if the barrier is
only "slightly" higher it won't be effective. Yes, aspects are discussed in
Section 12.5, but I believe it would be helpful if these issues got some
brief mention in the Background section, with specific attention paid to the
context set by RFC7340. If my text isn't perfect, can you tighten it up? I
note, by the way, that 12.5 says: "Relying on an Identity header field
generated by a remote administrative domain assumes that the issuing domain
uses recommended administrative practices to authenticate its users." What
are those "recommended administrative practices" - I could not find any in
the document nor a reference.

Regarding authentication of domain (not telephone number) URIs:

You say: "I don't think it constitutes much of a distraction, and in fact,
I'd say the solution would be incomplete without it." I indicated that my
preference would be to have it removed, but I offered alternatives if you
and/or others insist it be retained. The fact is that I found it
"distracting." There is some possibility that I am the only person that will
ever read the spec that found this to be the case. I (and I think others)
would like to be able to read the spec in a way that made it crystal clear
how to architect and implement a solution that works for telephone numbers.
Improving the separation between the telephone number and domain-based steps
would be helpful. 

I accept that I'm not going to get the help I want. If nothing else, I
suggest keeping the examples "pure" - in section 5, rather than having
12155551212 calling sip:[email-masked], use (or at least include) a phone
number to phone number example. And rather than sip:[email-masked],
use sip:[email-masked], since almost all real-world phone
number to phone number SIP traffic uses IP addresses and not domain names.
(See my calling name example below.) 

I'm glad you liked my nits. Speaking of nits, I note in the latest revision
you say: "The problem statement of STIR [RFC7340] focuses primarily on cases
where the called and calling parties identified in the To and From header
field values use telephone numbers, as this remains the dominant use case in
the deployment of SIP." The way I read RFC7340, it focuses ONLY on telephone
number cases (not "primarily").

On the more substantive points, my request is that, if you determine that my
(or somebody else's) suggestion is being made out of ignorance or
misunderstanding, you see if there isn't SOME tweak to the spec that might
be helpful in preventing others from making a similar error.

CALLING NAME DELIVERY EXAMPLE (USA) - how it works today:

An end-user, Fred, gets his service from a hosted PBX provider. Fred has
been assigned telephone number 1-212-555-4321. Fred places a call with his
IP phone to 1-415-555-6789; this is a mobile number assigned to Sally. The
SIP phone sends an INVITE to the hosted PBX provider which reoriginates the
call with an INVITE to their wholesale termination provider, with headers
that look like (in relevant part) TO: <sip:[email-masked]> and
FROM: "Fred Smith" <sip:[email-masked]>.

The termination provider reoriginates the call to their transit provider
with headers that look like (in relevant part) TO:
<sip:[email-masked]> and FROM:
<sip:[email-masked]>. Note that the Display Name has been
removed from the FROM header; they didn't need to do this, but it's their
practice.

The transit provider sends the call to Sally's mobile operator by
reoriginating the call using similar TO and FROM headers.

The mobile operator receives the call; it has gone SIP end-to-end from the
origination point. If Sally subscribes to the mobile operator's optional
"calling name" service, the mobile operator performs an SS7 TCAP CNAM query,
or something somewhat equivalent, supplying the telephone number from the TO
header (14155556789). The query returns, perhaps, "SMITH FRED" and the
mobile operator sends this over its air interface to Sally's phone for
display.

If Sally has NOT subscribed to the "calling name" service, the mobile
operator sends only the telephone number. Sally's smartphone looks this up
in her contact database; if it finds it, it displays the name; if not found,
it may display nothing, or it may have an alternate look-up mechanism which
might yield a name or a geographic indicator.

David Frankel

ZipDXR LLC

Monte Sereno, CA USA

From: stir [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Wednesday, August 24, 2016 12:38 AM
To: David Frankel <[email-masked]>; [email-masked]
Subject: Re: [stir] My Editorial Suggestions on RFC4474bis

Hi David,

You are correct that the first sentence of Section 3 sort of lumps
robocalling, voicemail hacking, and swatting into one bucket, and that
"enable" doesn't fit all the contents of that bucket equally well. Voicemail
hacking ("News of the World" style) is directly enabled by impersonation,
you can't do it without impersonation. I think I might say instead that
these practices "commonly leverage" an attacker's ability to impersonate
someone else's identity. I think though I'm going to end up removing this
text from the spec anyway, and instead slightly amplifying the text in the
introduction about RFC7340.

As to whether the mechanism described in the document "provides a strong
identity system for detecting attempted impersonation," I'm afraid I can't
agree with your reasons for saying that is incorrect. A lack of
implementation would not change whether or not the -document- describes such
a system. The presence or absence of an Identity header from any given SIP
message wouldn't change that either. This is a sentence about a document,
not about a deployment.  But again, I think this text will likely be removed
for unrelated reasons.

The specification is very careful to say that it does not protect caller
name, but it does so by saying that it doesn't protect display-name (the
text you indicate in 12.6), which is the way you carry a caller name in SIP.
There is no other commentary of any kind about how systems might derive
caller name in this specification, and I'd hesitate to introduce some. The
text in the second paragraph of 12.6 serves a very different purpose than
the paragraph you propose to replace it. I don't see any harm in noting that
telephone numbers are sometimes used to derive display names, but I see no
justification for having this specification deliver guidance on what sort of
name databases consumers should or should not trust.

I think some of your concerns about anonymity demonstrate how we use the
term differently in SIP than we might in everyday discourse. If you "achieve
true anonymity by spoofing somebody else's phone number (often, in fact,
just random numbers)" you are still spoofing a phone number. Your ability to
spoof telephone numbers enables that. What it is to claim anonymity in SIP
is to not divulge an individual identifier for yourself, usually by using
instead some kind of privacy service which sets your identity to something
that makes it clear that you want to remain anonymous. Impersonating random
telephone numbers is different - it is still impersonating numbers. As the
Privacy Considerations state, and state correctly I believe, "None of the
relevant attacks, all of which rely on the attacker taking on the identity
of a victim or hiding their identity using someone else's identity, are
enabled by anonymous identity."

As to the problem of abusive users obtaining telephone numbers "which they
can authenticate, but which still are ambiguous as to their ownership," this
is noted in the section on "Authorization and Transitional Strategies," as
are most of the similar concerns you raise here. We all know, for example,
that security vulnerabilities could allow attackers to compromise devices
that could make calls which possess totally valid credentials. No one here
thinks secure signaling is a silver bullet. However, the barrier to entry
for populating a From header field, versus compromising a device, is very
different. Similarly, the barrier to entry to acquiring "ambiguous"
telephone numbers is surely higher than just putting whatever comes to mind
in a From header field. The differences are real; I don't think we're
overselling them.

While I do agree that the STIR charter considers "greenfield" SIP URIs out
of scope, we long ago made a consensus decision in this working group not to
bar that text from rfc4474bis or any other proposals for solutions here.
STIR does not require this to solve its immediate threat model. However, as
we looked at gatewaying and so on, we quickly saw that there were going to
be cases where such identifiers would appear. I don't think it constitutes
much of a distraction, and in fact, I'd say the solution would be incomplete
without it.

Your nits are appreciated - this text is getting a pretty thorough
errata-vetting at this point.

Thanks,

Jon Peterson

Neustar, Inc.

From: stir <[email-masked] <mailto:[email-masked]> > on behalf
of David Frankel <[email-masked] <mailto:[email-masked]> >
Organization: ZipDX LLC
Date: Sunday, August 21, 2016 at 10:17 AM
To: "[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: [stir] My Editorial Suggestions on RFC4474bis

OBJECTIVES / PURPOSE

We still need a discussion of the other half of the problem (per RFC7340),
which is ANONYMIZATION of the calling party. What I see today in 4474bis
addresses forms such as  <mailto:"[email-masked]>
"[email-masked]" where the caller explicitly declares anonymity. This
is really related to privacy, which is why 4474bis has it in a section with
that title. 

Given this, 4474bis should not contain, to the extent that it does,
references to authenticating From headers containing [email-masked]
<mailto:[email-masked]>  or [email-masked] <mailto:[email-masked]> .
(These appear repeatedly in Sections 1, 4, 6, and 7.) There is also text
about "signing for a domain." 

If there is insistence that it be included here (despite the mandate in the
charter that "expansion...using user@domain...is <mailto:user@domain...is>
out of scope"), then it should be collected and placed in an appendix
outside the primary flow of the document. I do realize the value of being
forward-looking. At the same time, there is such urgency in getting STIR
deployed for telephone numbers that I don't think we can afford the
distraction.

ERRATA

 

David Frankel

ZipDXR LLC

Monte Sereno, CA USA

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2016 22:41:31 -0700

On Aug 24, 2016, at 6:31 PM, David Frankel <[email-masked]> wrote:
>  
> CALLING NAME DELIVERY EXAMPLE (USA) – how it works today:
> An end-user, Fred, gets his service from a hosted PBX provider. Fred has been assigned telephone number 1-212-555-4321. Fred places a call with his IP phone to 1-415-555-6789; this is a mobile number assigned to Sally. The SIP phone sends an INVITE to the hosted PBX provider which reoriginates the call with an INVITE to their wholesale termination provider, with headers that look like (in relevant part) TO: <sip:[email-masked]> and FROM: “Fred Smith” <sip:[email-masked]>.
>  
> The termination provider reoriginates the call to their transit provider with headers that look like (in relevant part) TO: <sip:[email-masked]> and FROM:  <sip:[email-masked]>. Note that the Display Name has been removed from the FROM header; they didn’t need to do this, but it’s their practice.

[BA] This is a good example since it highlights some of the issues with SP-only signing.

Due to the reorigination, even if we did have SP signing, the SIP headers may not provide enough information to enable traceback since only the wholesale provider signature is available (and the hosted PBX provider may be obscured). And there are reasons why even that could be absent.

The hosted PBX provider and the wholesale termination provider may be different, and the hosted PBX provider while being able to authenticate endpoints, may have no ability to verify TN authorization, since it did not assign the TNs. Also, the wholesale provider may be presented with calls originating from TNs outside its authority. As an example, PBXes frequently have PSTN lines for backup in event of an Internet outage and may use those PSTN TNs as the originator for emergency service calls that could be sent using VOIP even when there is no outage. The wholesaler did not assign those TNs so has no ability to verify their authorization.

>  
> The transit provider sends the call to Sally’s mobile operator by reoriginating the call using similar TO and FROM headers.
>  
> The mobile operator receives the call; it has gone SIP end-to-end from the origination point. If Sally subscribes to the mobile operator’s optional “calling name” service, the mobile operator performs an SS7 TCAP CNAM query, or something somewhat equivalent, supplying the telephone number from the TO header (14155556789). The query returns, perhaps, “SMITH FRED” and the mobile operator sends this over its air interface to Sally’s phone for display.
>  
> If Sally has NOT subscribed to the “calling name” service, the mobile operator sends only the telephone number. Sally’s smartphone looks this up in her contact database; if it finds it, it displays the name; if not found, it may display nothing, or it may have an alternate look-up mechanism which might yield a name or a geographic indicator.
>  
>  
> David Frankel
> ZipDX® LLC
> Monte Sereno, CA USA
> To: "[email-masked]" <[email-masked]>
> Given this, 4474bis should not contain, to the extent that it does, references to authenticating >From headers containing [email-masked] or [email-masked]. (These appear repeatedly in Sections 1, 4, 6, and 7.) There is also text about “signing for a domain.”
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Aug 2016 09:21:15 -0400

> On Aug 25, 2016, at 1:41 AM, Bernard Aboba <[email-masked]> wrote:
> 
> On Aug 24, 2016, at 6:31 PM, David Frankel <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> An end-user, Fred, gets his service from a hosted PBX provider. Fred has been assigned telephone number 1-212-555-4321. Fred places a call with his IP phone to 1-415-555-6789; this is a mobile number assigned to Sally. The SIP phone sends an INVITE to the hosted PBX provider which reoriginates the call with an INVITE to their wholesale termination provider, with headers that look like (in relevant part) TO: <sip:[email-masked] <mailto:[email-masked]>> and FROM: “Fred Smith” <sip:[email-masked] <mailto:[email-masked]>>.
>>  
>> The termination provider reoriginates the call to their transit provider with headers that look like (in relevant part) TO: <sip:[email-masked] <mailto:[email-masked]>> and FROM:  <sip:[email-masked] <mailto:[email-masked]>>. Note that the Display Name has been removed from the FROM header; they didn’t need to do this, but it’s their practice.

The canonicalization would use only the phone number, so the fact that the domain was re-written doesn’t matter.  This also means that editing out the display name doesn’t matter.

Any of the device, the hosted PBX or the wholesale termination provider (assuming the wholesale provider delegated the TN to the hosted PBX provider) can sign.  If the wholesale termination provider signs, he does so with knowledge that he can pass the hot potato to the hosted PBX provider.  That hosted PBX provider will be left holding it if he doesn’t really know who Fred is.  If he does, then he gets to pass it to Fred.  The wholesale termination provider is very likely to not tolerate bad calls coming from the hosted PBX provider, regardless of which of the hosted PBX provider’s customers are at fault.  So, that hosted PBX provider will likely have to cut off Fred if the PBX provider wants to keep his termination service.

> Due to the reorigination, even if we did have SP signing, the SIP headers may not provide enough information to enable traceback since only the wholesale provider signature is available (and the ho…
The wholesale termination provider knows that he delegated Fred’s TN to the hosted PBX provider.  So, as long as the TN arrives intact, which happens in this example, the hot potato can be handed to the hosted PBX provider.  Whether it can be handed to Fred is up to the hosted PBX provider. but from our point of view, the mechanism allows the signer (we’re assuming the wholesale termination provider) to avoid the gauze of law enforcement by being able to hand the potato to the hosted PBX provider.  That wholesale termination provider had better make sure that the TN is one of the TNs that it assigned to the hosted PBX provider or it may be left holding the potato.
> 
> The hosted PBX provider and the wholesale termination provider may be different, and the hosted PBX provider while being able to authenticate endpoints, may have no ability to verify TN authorization, since it did not assign the TNs.
<broke here>I think that is incorrect.  The wholesale termination provider is the service provider of record (in the US, via NANPA or PA delegation, or port in).  This is not a case of “authorized spoofing”.  It’s Fred’s number, but it the actual delegation processes is to to the wholesale termination provider and to the hosted PBX provider.  In the current scheme, the hosted PBX provider controls the number, and the wholesale termination provider is the one to whom calls are routed in the PSTN.

> Also, the wholesale provider may be presented with calls originating from TNs outside its authority. As an example, PBXes frequently have PSTN lines for backup in event of an Internet outage and may use those PSTN TNs as the originator for emergency service calls that could be sent using VOIP even when there is no outage. The wholesaler did not assign those TNs so has no ability to verify their authorization.
There are cases where wholesale termination providers have allowed their customers to originate calls that have a TN not delegated to the customer by the termination provider.  I use the term “authorized spoofing” for them.  This is the call center that calls on behalf of an enterprise.  You have another case, where there is a backup set of trunks to a second provider and the second provider will allow calls to be sent on those trunks from the TN delegated by the primary provider.  In the stir scheme, the wholesale termination provider would need to be authorized by the primary provider to sign calls with those TNs.  That’s not a particularly onerous process, but it’s a new process.

>> Watch Our Video! <http://www.zipdx.info/features/>
>>  
>> From: stir [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Peterson, Jon
>> To: David Frankel <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of David Frankel <[email-masked] <mailto:[email-masked]>>
>> Organization: ZipDX LLC
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> We still need a discussion of the other half of the problem (per RFC7340), which is ANONYMIZATION of the calling party. What I see today in 4474bis addresses forms such as “[email-masked] <mailto:[email-masked]>” where the caller explicitly declares anonymity. This is really related to privacy, which is why 4474bis has it in a section with that title. 
>>  
>> Given this, 4474bis should not contain, to the extent that it does, references to authenticating >From headers containing [email-masked] <mailto:[email-masked]> or [email-masked] <mailto:[email-masked]>. (These appear repeatedly in Sections 1, 4, 6, and 7.) There is also text about “signing for a domain.” 
>>  
>> If there is insistence that it be included here (despite the mandate in the charter that “expansion...using user@domain...is <mailto:user@domain...is> out of scope”), then it should be collected and placed in an appendix outside the primary flow of the document. I do realize the value of being forward-looking. At the same time, there is such urgency in getting STIR deployed for telephone numbers that I don’t think we can afford the distraction.
>>  
>> Watch Our Video! <http://www.zipdx.info/features/>
>>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Aug 2016 07:11:32 -0700

On 8/24/2016 10:41 PM, Bernard Aboba wrote:
> PBXes frequently have PSTN lines for backup in event of an Internet
> outage and may use those PSTN TNs as the originator for emergency
> service calls that could be sent using VOIP even when there is no
> outage. The wholesaler did not assign those TNs so has no ability to
> verify their authorization.

Some of this might hinge on the semantics for a signature.  The obvious 
and reasonable semantic to have is:

      "the entity using this telephone number has official authority to 
use this telephone number."

in that case, there is the problem you observe.

Among the alternative semantics is:

     "the entity using this telephone number is assessed to be good actor."

That is, validate the actor, not the telephone number.  In this case, 
the wholesaler /can/ sign for the usage.

A more cumbersome alternative is for the PBX to register the alternative 
phone numbers with the wholesaler, ahead of time.  This requires some 
additional mechanism for the wholesaler to validate the registration.

d/

-- 

   Dave Crocker