Subject: Re: [cnit] CNIT Charter bashing..

From: Richard Shockey <[email-masked]>
Date: Thu, 11 Jun 2015 11:46:07 -0400

Thank you that is very helpful. I¹m assuming its network delivered based on
information derived from the calling party billing data.

My other running assumption has been that some form Advanced Calling Name
Delivery is a precondition for advanced realtime communications service
delivery.. Aka ubiquitous video calling.   Would that be a reasonable
presumption?

From:  <[email-masked]>
Date:  Thursday, June 11, 2015 at 9:02 AM
To:  "[email-masked]" <[email-masked]>
Subject:  Re: [cnit] CNIT Charter bashing..

Richard,

For a number of years, there has been an optional caller name dispay feature
attached to some of the telephone services in France, but indeed nothing
like the standalone CNAM service concept that underpins the discussions on
this list.

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : Richard Shockey
Date :11/06/2015 05:21 (GMT+01:00)
À : Brian Rosen , Henning Schulzrinne
Cc : [email-masked] 
Objet : Re: [cnit] CNIT Charter bashing..

Here is what I want to know now.

Before we start to process this concept I want to know how relevant the
existing CNAM service is deployed outside North America.

I¹m told by reliable sources that the CNAM service is not deployed anywhere
among the major telecom markets in Europe or Asia. Not Japan China or South
Korea UK Italy France and in fact it might actually be illegal under the
strict privacy regulations in Germany.

I don¹t know. 

That said our friends at Apple seem to understand there is a problem here. I
have tried to engage the most senior management at Google about who would be
responsible for defining how the VoLTE CUA could actually display an
advanced call display data and frankly no one knows.

http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015-
6

There is a realistic question if this is simply a North American specific
problem why is this  a IETF issue. You might ask the same question of MODERN
but I frankly don¹t want to go there.

From: Richard Shockey <[email-masked]>
Date: Tuesday, June 2, 2015 at 12:35 PM
To: Brian Rosen <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [cnit] CNIT Charter bashing..

Hopefully but I still haven¹t seen any response to my concern about
normative dependencies on STIR.

If we can define the object/headers first then I don¹t have a issue.

‹ 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

From: Brian Rosen <[email-masked]>
Date: Tuesday, June 2, 2015 at 12:26 PM
To: Richard Shockey <[email-masked]>
Cc: Eric Burger <[email-masked]>, <[email-masked]>
Subject: Re: [cnit] CNIT Charter bashing..

Are we planning to submit a charter in the next couple of days, and then see
if we can get a slot at the next IETF?

Brian
> On May 28, 2015, at 1:55 PM, Richard Shockey <[email-masked]> wrote:
> 
> 
> A fair argument but I don¹t want to spend 5 years waiting for a series of
> normative dependencies on the trust model before actually understanding what
> headers can/should be used here.
> 
> 
> Its much too difficult to get things done in the IETF as it is.   I¹d much
> prefer building from success starting with the definition of the data object
> then ..then folding that into a trust model and frankly given what we have
> seen in STIR I¹m not sure your argument holds up. Again the MARTINI model.
> 
> Didn¹t you recently  say something about ³perfection is the enemy of the good²
> :-) 
> 
> 
> 
> From: Eric Burger <[email-masked]>
> Date: Wednesday, May 27, 2015 at 10:11 PM
> To: <[email-masked]>
> Subject: Re: [cnit] CNIT Charter bashing..
> 
> On May 25, 2015, at 5:31 PM, Richard Shockey <[email-masked]> wrote:
>> 
>> From: Mary Barnes <[email-masked]>
>> Date: Friday, May 22, 2015 at 12:58 PM
>> Attached is what I have at this point. Really, the only thing I'm struggling
>> with is the milestones as I don't think we can request publication of the
>> data object and headers without having defined the trust model.
>> 
>> 
>> RS> Mary I¹m not sure about that statement. I can certainly anticipate
>> several deployment models where the trust mechanism (aka signing) does not
>> need to be formally integrated in the solution especially those where the
>> exchange of data is more bi-lateral and the trust mechanism is at lower
>> layers of the stack than the signaling. My initial concern  is what is the
>> header and what is the data object(s) carried in the header. How the CNIT
>> data is created should not be our concern.
> 
> I do not buy it. If there are private agreements between service providers,
> they have private agreements. They can do whatever they want.
> 
> Last I looked, this is the Internet Engineering Task Force. Assume untrusted
> transport across the wide open Internet, and trust no endpoint that cannot
> cryptographically prove who they are. If it happens two service providers
> exchange CNIT data over a single, yellow cable, then it is a benefit that no
> state-sponsored security service can listen in on the cable.
> 
> I do not want to take three years to build a protocol and two more years after
> that for products to be available just to have a system that only works in
> walled gardens. I do not want to be the person that has to explain to the
> media why Calling Name Delivery is just as broken as it always was and it will
> be another five years before the world sees a real solution.
> 
> Let us get this right the first time.
> [snip]
> _______________________________________________ cnit mailing list
> [email-masked]://www.ietf.org/mailman/listinfo/cnit
> _______________________________________________
> cnit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cnit

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

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________ cnit mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/cnit

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 11 Jun 2015 16:18:29 +0000

I got a different answer from the Orange/FT folks at the CT WG meetings.....so please check and clarify....

From: cnit [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Thursday, June 11, 2015 11:46 AM
To: [email-masked]; [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Thank you that is very helpful. I'm assuming its network delivered based on information derived from the calling party billing data.

My other running assumption has been that some form Advanced Calling Name Delivery is a precondition for advanced realtime communications service delivery.. Aka ubiquitous video calling.   Would that be a reasonable presumption?

From: <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 11, 2015 at 9:02 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [cnit] CNIT Charter bashing..

Richard,

For a number of years, there has been an optional caller name dispay feature attached to some of the telephone services in France, but indeed nothing like the standalone CNAM service concept that underpins the discussions on this list.

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : Richard Shockey
Date :11/06/2015 05:21 (GMT+01:00)
À : Brian Rosen , Henning Schulzrinne
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [cnit] CNIT Charter bashing..

Before we start to process this concept I want to know how relevant the existing CNAM service is deployed outside North America.

I'm told by reliable sources that the CNAM service is not deployed anywhere among the major telecom markets in Europe or Asia. Not Japan China or South Korea UK Italy France and in fact it might actually be illegal under the strict privacy regulations in Germany.

I don't know.

That said our friends at Apple seem to understand there is a problem here. I have tried to engage the most senior management at Google about who would be responsible for defining how the VoLTE CUA could actually display an advanced call display data and frankly no one knows.

http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015-6

There is a realistic question if this is simply a North American specific problem why is this  a IETF issue. You might ask the same question of MODERN but I frankly don't want to go there.

From: Richard Shockey <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 2, 2015 at 12:35 PM
To: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [cnit] CNIT Charter bashing..

Hopefully but I still haven't seen any response to my concern about normative dependencies on STIR.

If we can define the object/headers first then I don't have a issue.

-
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us<http://www.shockey.us>
www.sipforum.org<http://www.sipforum.org>
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 2, 2015 at 12:26 PM
To: Richard Shockey <[email-masked]<mailto:[email-masked]>>
Cc: Eric Burger <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [cnit] CNIT Charter bashing..

Are we planning to submit a charter in the next couple of days, and then see if we can get a slot at the next IETF?

Brian
On May 28, 2015, at 1:55 PM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:

A fair argument but I don't want to spend 5 years waiting for a series of normative dependencies on the trust model before actually understanding what headers can/should be used here.

Its much too difficult to get things done in the IETF as it is.   I'd much prefer building from success starting with the definition of the data object then ..then folding that into a trust model and frankly given what we have seen in STIR I'm not sure your argument holds up. Again the MARTINI model.

Didn't you recently  say something about "perfection is the enemy of the good"  :-)

From: Eric Burger <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 27, 2015 at 10:11 PM
To: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [cnit] CNIT Charter bashing..

On May 25, 2015, at 5:31 PM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:

From: Mary Barnes <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 22, 2015 at 12:58 PM
Attached is what I have at this point. Really, the only thing I'm struggling with is the milestones as I don't think we can request publication of the data object and headers without having defined the trust model.

RS> Mary I'm not sure about that statement. I can certainly anticipate several deployment models where the trust mechanism (aka signing) does not need to be formally integrated in the solution especially those where the exchange of data is more bi-lateral and the trust mechanism is at lower layers of the stack than the signaling. My initial concern  is what is the header and what is the data object(s) carried in the header. How the CNIT data is created should not be our concern.

I do not buy it. If there are private agreements between service providers, they have private agreements. They can do whatever they want.

Last I looked, this is the Internet Engineering Task Force. Assume untrusted transport across the wide open Internet, and trust no endpoint that cannot cryptographically prove who they are. If it happens two service providers exchange CNIT data over a single, yellow cable, then it is a benefit that no state-sponsored security service can listen in on the cable.

I do not want to take three years to build a protocol and two more years after that for products to be available just to have a system that only works in walled gardens. I do not want to be the person that has to explain to the media why Calling Name Delivery is just as broken as it always was and it will be another five years before the world sees a real solution.

Let us get this right the first time.
[snip]
_______________________________________________ cnit mailing list [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/cnit
_______________________________________________
cnit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cnit

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 11 Jun 2015 17:08:07 +0000

The topic of caller name delivery came up (along with STIR and other topics) at a recent event:

http://www.aging.senate.gov/hearings/ringing-off-the-hook_examining-the-proliferation-of-unwanted-calls

CNIT is making a cameo appearance as well. I would summarize the event as "bipartisan frustration with the status quo".

________________________________
From: cnit [[email-masked]] on behalf of Richard Shockey [[email-masked]]
Sent: Thursday, June 11, 2015 11:46 AM
To: [email-masked]; [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Thank you that is very helpful. I’m assuming its network delivered based on information derived from the calling party billing data.

Richard,

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : Richard Shockey

I’m told by reliable sources that the CNAM service is not deployed anywhere among the major telecom markets in Europe or Asia. Not Japan China or South Korea UK Italy France and in fact it might actually be illegal under the strict privacy regulations in Germany.

I don’t know.

There is a realistic question if this is simply a North American specific problem why is this  a IETF issue. You might ask the same question of MODERN but I frankly don’t want to go there.

Hopefully but I still haven’t seen any response to my concern about normative dependencies on STIR.

If we can define the object/headers first then I don’t have a issue.

—
Richard Shockey
Shockey Consulting LLC

Brian

A fair argument but I don’t want to spend 5 years waiting for a series of normative dependencies on the trust model before actually understanding what headers can/should be used here.

Its much too difficult to get things done in the IETF as it is.   I’d much prefer building from success starting with the definition of the data object then ..then folding that into a trust model and frankly given what we have seen in STIR I’m not sure your argument holds up. Again the MARTINI model.

Didn’t you recently  say something about “perfection is the enemy of the good”  :-)

RS> Mary I’m not sure about that statement. I can certainly anticipate several deployment models where the trust mechanism (aka signing) does not need to be formally integrated in the solution especially those where the exchange of data is more bi-lateral and the trust mechanism is at lower layers of the stack than the signaling. My initial concern  is what is the header and what is the data object(s) carried in the header. How the CNIT data is created should not be our concern.

---

From: <[email-masked]>
Date: Thu, 11 Jun 2015 18:00:13 +0000

The feature I was referring to
http://assistance.orange.fr/presentation-du-nom-de-la-ligne-fixe-utilisation-4010.php
(In French, with my apologies)
As I said, it isn't a CNAM service.

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : "DOLLY, MARTIN C"
Date :11/06/2015 18:18 (GMT+01:00)
À : Richard Shockey , FOUQUART Philippe IMT/OLN , [email-masked]
Objet : RE: [cnit] CNIT Charter bashing..

I got a different answer from the Orange/FT folks at the CT WG meetings…..so please check and clarify….

Richard,

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : Richard Shockey

I don’t know.

—
Richard Shockey
Shockey Consulting LLC

Brian

Thank you.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 11 Jun 2015 18:05:14 +0000

>From my reading, the function seems similar to caller name delivery, even if the mechanism is not a CNAM database.

According to Google Translate:

Presented coordinates are those listed in the directories. These are necessarily the coordinates of the line holder that are displayed. The name of the calling line holder is displayed only if the call is presented on a compatible device.

________________________________
From: cnit [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Thursday, June 11, 2015 2:00 PM
To: DOLLY, MARTIN C; Richard Shockey; [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : "DOLLY, MARTIN C"

Richard,

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : Richard Shockey

I don’t know.

—
Richard Shockey
Shockey Consulting LLC

Brian

Thank you.

---

From: Richard Shockey <[email-masked]>
Date: Thu, 11 Jun 2015 15:37:57 -0400

On 6/11/15, 1:08 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>CNIT is making a cameo appearance as well. I would summarize the event as
>"bipartisan frustration with the status quo".

Yep Š   

http://thehill.com/policy/technology/244566-senators-pile-on-the-robocall-b
ashing

>Thank you that is very helpful. I¹m assuming its network delivered based
>on information derived from the calling party billing data.
>
>For a number of years, there has been an optional caller name dispay
>feature attached to some of the telephone services in France, but indeed
>nothing like the standalone CNAM service concept that underpins the
>discussions on this list.
>
>Regards,
>
>Philippe Fouquart
>Orange Labs Networks
>+33 (0) 1 45 29 58 13
>
>
>I¹m told by reliable sources that the CNAM service is not deployed
>anywhere among the major telecom markets in Europe or Asia. Not Japan
>China or South Korea UK Italy France and in fact it might actually be
>illegal under the strict privacy regulations in Germany.
>
>I don¹t know.
>
>That said our friends at Apple seem to understand there is a problem
>here. I have tried to engage the most senior management at Google about
>who would be responsible for defining how the VoLTE CUA could actually
>display an advanced call display data and frankly no one knows.
>
>problem why is this  a IETF issue. You might ask the same question of
>MODERN but I frankly don¹t want to go there.
>
>
>
>
>Cc: Eric Burger 
><[email-masked]<mailto:[email-masked]>>,
><[email-masked]<mailto:[email-masked]>>
>Are we planning to submit a charter in the next couple of days, and then
>see if we can get a slot at the next IETF?
>
>Brian
>On May 28, 2015, at 1:55 PM, Richard Shockey
><[email-masked]<mailto:[email-masked]>> wrote:
>
>
>normative dependencies on the trust model before actually understanding
>what headers can/should be used here.
>
>
>Its much too difficult to get things done in the IETF as it is.   I¹d
>much prefer building from success starting with the definition of the
>data object then ..then folding that into a trust model and frankly given
>what we have seen in STIR I¹m not sure your argument holds up. Again the
>MARTINI model.
>
>Didn¹t you recently  say something about ³perfection is the enemy of the
>good²  :-)
>
>
>
>From: Eric Burger 
><[email-masked]<mailto:[email-masked]>>
>On May 25, 2015, at 5:31 PM, Richard Shockey
><[email-masked]<mailto:[email-masked]>> wrote:
>
>From: Mary Barnes 
><[email-masked]<mailto:[email-masked]>>
>Attached is what I have at this point. Really, the only thing I'm
>struggling with is the milestones as I don't think we can request
>publication of the data object and headers without having defined the
>trust model.
>
>
>several deployment models where the trust mechanism (aka signing) does
>not need to be formally integrated in the solution especially those where
>the exchange of data is more bi-lateral and the trust mechanism is at
>lower layers of the stack than the signaling. My initial concern  is what
>is the header and what is the data object(s) carried in the header. How
>the CNIT data is created should not be our concern.
>
>I do not buy it. If there are private agreements between service
>providers, they have private agreements. They can do whatever they want.
>
>Last I looked, this is the Internet Engineering Task Force. Assume
>untrusted transport across the wide open Internet, and trust no endpoint
>that cannot cryptographically prove who they are. If it happens two
>service providers exchange CNIT data over a single, yellow cable, then it
>is a benefit that no state-sponsored security service can listen in on
>the cable.
>
>I do not want to take three years to build a protocol and two more years
>after that for products to be available just to have a system that only
>works in walled gardens. I do not want to be the person that has to
>explain to the media why Calling Name Delivery is just as broken as it
>always was and it will be another five years before the world sees a real
>solution.
>
>[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/c
>nit
>__________________________________________________________________________
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler

---

From: <[email-masked]>
Date: Fri, 12 Jun 2015 10:11:52 +0000

As far as what the feature does, I think you are right. And after all, displaying a name is..., well just that really, displaying a name and the variations are mostly around whether the source is authoritative or to what extent.  

As to the misunderstanding relative to whether this is or isn't implemented, I know that this hasn't been massively successful as a feature and the need to replicate that beyond TDM isn't clear. It would seem that most people would consider at this stage that "matching-CLI-with-names-in-Contacts-and-displaying-the-CLI-or-anonymous-when-not-present" is just good enough. Displaying names was a challenge in environments and days when contact books weren't available and although from an engineering perspective, not having a single format to display may not be satisfactory or ideal for both CgP and CdP, it may actually be a de facto happy medium for their conflicting needs for privacy/information respectively.  Probably slightly off topic for this list.  

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Message d'origine-----
De : Henning Schulzrinne [mailto:[email-masked]] 
Envoyé : jeudi 11 juin 2015 20:05
À : FOUQUART Philippe IMT/OLN; [email-masked]
Objet : RE: [cnit] CNIT Charter bashing..

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : "DOLLY, MARTIN C"
Date :11/06/2015 18:18 (GMT+01:00)
À : Richard Shockey , FOUQUART Philippe IMT/OLN , [email-masked] Objet : RE: [cnit] CNIT Charter bashing..

I got a different answer from the Orange/FT folks at the CT WG meetings...so please check and clarify..

Richard,

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : Richard Shockey

I don't know.

-
Richard Shockey
Shockey Consulting LLC

Brian

Thank you.

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jun 2015 13:13:24 +0000

>From what I can tell, North American businesses see a fair amount of value in this feature, as many people (due to robocalls) won't pick up anonymous calls or calls from numbers they do not recognize. In addition, this address book has to be created somehow. It's a whole lot easier to auto-populate the name from the caller name information than asking users to type in the name for the person that just called them. After all, that's how typical email-derived address books work - people don't type in that information.

I suspect we'll see, as in the Apple announcement, various third-party kludges that go beyond the personal address book, where Google and Apple (and, with a year or two delay, Microsoft) try to use their own data, web page data and maybe crowd-sourced data to create a pseudo-CNAM, with a proprietary architecture and opaque data sources. This will work ok to the point where a business finds that their name is horribly mangled and then tries to determine how they can get it fixed by somebody they can't talk to.

That said, we're talking about a SIP feature (display name) that already exists and is, I assume, widely used for enterprise VoIP systems. Thus, my goal is modest: allow signed and extended versions of the display name. 

I find it peculiar that carriers always say that they want to be more than bit pipes, but then find all kinds of reasons not to add value to their services. This obviously only applies to people and organizations not on this list :-)

Henning

________________________________________
From: cnit [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Friday, June 12, 2015 6:11 AM
To: [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Message d'origine-----
De : Henning Schulzrinne [mailto:[email-masked]]
Envoyé : jeudi 11 juin 2015 20:05
À : FOUQUART Philippe IMT/OLN; [email-masked]
Objet : RE: [cnit] CNIT Charter bashing..

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : "DOLLY, MARTIN C"

Richard,

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : Richard Shockey

I don't know.

-
Richard Shockey
Shockey Consulting LLC

Brian

Thank you.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 12 Jun 2015 09:36:39 -0400

In line

On 6/12/15, 9:13 AM, "Henning Schulzrinne" <[email-masked]>
wrote:

>>From what I can tell, North American businesses see a fair amount of
>>value in this feature, as many people (due to robocalls) won't pick up
>>anonymous calls or calls from numbers they do not recognize. In
>>addition, this address book has to be created somehow. It's a whole lot
>>easier to auto-populate the name from the caller name information than
>>asking users to type in the name for the person that just called them.
>>After all, that's how typical email-derived address books work - people
>>don't type in that information.
>
>I suspect we'll see, as in the Apple announcement, various third-party
>kludges that go beyond the personal address book, where Google and Apple
>(and, with a year or two delay, Microsoft) try to use their own data, web
>page data and maybe crowd-sourced data to create a pseudo-CNAM, with a
>proprietary architecture and opaque data sources. This will work ok to
>the point where a business finds that their name is horribly mangled and
>then tries to determine how they can get it fixed by somebody they can't
>talk to.

RS> Amen ..

>
>That said, we're talking about a SIP feature (display name) that already
>exists and is, I assume, widely used for enterprise VoIP systems. Thus,
>my goal is modest: allow signed and extended versions of the display name.

RS> Well intra enterprise certainly.  There it tends to get pulled from
Active Directory but until we can get the NNI interface deployed its not
working at all for inter enterprise.  We are certainly looking at that for
Phase 2 of the NNI TF.

My goal is some what more modest for a first phase.  Certainly you want
signed extended versions of the display name but one should not create
artificial barriers to non signed data exchanges between service providers
where the security comes from the big yellow wire at Layer 1.  Plus I
still want a straight answer if this proposal is going to have a
requirement for a new SIP header and all the IETF ART pain and suffering
that goes with that. I want the AD¹s to make that demand ( if it is to be
imposed) explicit now.

> 
>
>I find it peculiar that carriers always say that they want to be more
>than bit pipes, but then find all kinds of reasons not to add value to
>their services. This obviously only applies to people and organizations
>not on this list :-)

>From: cnit [[email-masked]] on behalf of
>[email-masked] [[email-masked]]
>As far as what the feature does, I think you are right. And after all,
>displaying a name is..., well just that really, displaying a name and the
>variations are mostly around whether the source is authoritative or to
>what extent.
>
>As to the misunderstanding relative to whether this is or isn't
>implemented, I know that this hasn't been massively successful as a
>feature and the need to replicate that beyond TDM isn't clear. It would
>seem that most people would consider at this stage that
>"matching-CLI-with-names-in-Contacts-and-displaying-the-CLI-or-anonymous-w
>hen-not-present" is just good enough. Displaying names was a challenge in
>environments and days when contact books weren't available and although
>from an engineering perspective, not having a single format to display
>may not be satisfactory or ideal for both CgP and CdP, it may actually be
>a de facto happy medium for their conflicting needs for
>privacy/information respectively.  Probably slightly off topic for this
>list.
>
>Philippe Fouquart
>Orange Labs Networks
>+33 (0) 1 45 29 58 13
>
>>From my reading, the function seems similar to caller name delivery,
>>even if the mechanism is not a CNAM database.
>
>Presented coordinates are those listed in the directories. These are
>necessarily the coordinates of the line holder that are displayed. The
>name of the calling line holder is displayed only if the call is
>presented on a compatible device.
>
>From: cnit [[email-masked]] on behalf of
>[email-masked] [[email-masked]]
>Thank you that is very helpful. I'm assuming its network delivered based
>I'm told by reliable sources that the CNAM service is not deployed
>MODERN but I frankly don't want to go there.
>
>
>
>
>A fair argument but I don't want to spend 5 years waiting for a series of
>Its much too difficult to get things done in the IETF as it is.   I'd
>what we have seen in STIR I'm not sure your argument holds up. Again the
>MARTINI model.
>
>RS> Mary I'm not sure about that statement. I can certainly anticipate
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>exploites ou copies sans autorisation. Si vous avez recu ce message par
>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
>pieces jointes. Les messages electroniques etant susceptibles
>d'alteration, Orange decline toute responsabilite si ce message a ete
>altere, deforme ou falsifie. Merci.
>
>information that may be protected by law; they should not be distributed,
>used or copied without authorisation.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jun 2015 14:07:19 +0000

There seem to be three levels:

(1) Make existing SIP display name information survive NNI and VoIP-to-TDM translation. The ATIS-SIPForum effort seems to be an appropriate venue for that as it involves no new SIP headers or SIP behavior.

(2) Allow for (but not mandate) signing the display name. We need to determine whether this is just another STIR special case or not. This applies to the (common) case where the signer of the SIP request is also in a position to validate the caller name, using whatever internal policies they may have. (In some cases, this is simply whatever the subscriber typed into a web form, so this isn't perfect, but since the number signing will provide traceability, the FBI and IRS along with HSBC and Microsoft know whom to talk to if a customer of Joe's VoIP Service & Salvage asserts those identities. Trademark law and civil fraud statutes seem to cover that case; the main practical difficulty today is that finding the source of the information is impossible.)

(3) Better caller name information that allows parties other than the carrier to assert additional information.

Does that cover the options?

Henning

________________________________________
From: Richard Shockey [[email-masked]]
Sent: Friday, June 12, 2015 9:36 AM
To: Henning Schulzrinne; [email-masked]; [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

---

From: Richard Shockey <[email-masked]>
Date: Fri, 12 Jun 2015 09:50:50 -0400

In North America it has been wildly popular and indeed considered
essential offering for the competitive voice providers aka cable. Its a
good business.  There is actually consensus in the NA industry if you want
interconnected point to point video to deploy some enhancement to the
service is essential. The contact in the phone book is not enough. Ok sure
for the 65% of calls that are part of the 20-40 numbers in your dialer but
there are other applications here such as public safety where
authenticated identity of the calling party may have significant benefits.

It it my understanding that there are valid concerns about the
Privacy/Information issues etc but really who¹s privacy are you
protecting? The calling party or the called party.  I¹ve heard the
arguments. Its actually a very very interesting debate.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jun 2015 14:13:19 +0000

In almost all cases of interest, the calling party *wants* to disclose accurate information to the called party, so the privacy issues don't seem to arise. They would only arise if there was forced disclosure; I don't think anybody is proposing that.

Sent: Friday, June 12, 2015 9:50 AM

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Jun 2015 15:17:08 +0100

On 12/06/15 15:13, Henning Schulzrinne wrote:
> In almost all cases of interest, the calling party *wants* to
> disclose accurate information to the called party, so the privacy
> issues don't seem to arise. They would only arise if there was forced
> disclosure; I don't think anybody is proposing that.

Privacy issues could also arise if a middlebox could now see
sensitive information that it previously could not see. I think
that is independent of whether disclosure is desired by either
of the endpoints.

S.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jun 2015 15:47:15 +0000

Good point, although I suspect that a business or individual that wants to disclose its name to the recipient and obviously already discloses its number to all carriers along the way seems unlikely to care that the carrier can also see its name. After all, today, all such carriers have access to CNAM information (along with others). At least in the US, the carriers are largely bound by strict privacy rules ("customer proprietary network information") that carriers tend to take very seriously. (I say "largely", because there may be entities such as CNAM providers and VoIP providers that are considering themselves not to be interconnected that are in the not-quite-carrier area.)

________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Friday, June 12, 2015 10:17 AM
To: Henning Schulzrinne; Richard Shockey; [email-masked]; [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

S.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 12 Jun 2015 11:41:45 -0400

On 6/12/15, 10:07 AM, "Henning Schulzrinne" <[email-masked]>
wrote:

>(1) Make existing SIP display name information survive NNI and
>VoIP-to-TDM translation. The ATIS-SIPForum effort seems to be an
>appropriate venue for that as it involves no new SIP headers or SIP
>behavior.

RS> Correct. That is definitely on the agenda for Phase 2 of the NNI.

>
>(2) Allow for (but not mandate) signing the display name. We need to
>determine whether this is just another STIR special case or not. This
>applies to the (common) case where the signer of the SIP request is also
>in a position to validate the caller name, using whatever internal
>policies they may have. (In some cases, this is simply whatever the
>subscriber typed into a web form, so this isn't perfect, but since the
>number signing will provide traceability, the FBI and IRS along with HSBC
>and Microsoft know whom to talk to if a customer of Joe's VoIP Service &
>Salvage asserts those identities. Trademark law and civil fraud statutes
>seem to cover that case; the main practical difficulty today is that
>finding the source of the information is impossible.)

RS> Correct. My initial use case is a relatively simple voluntary
extension of the existing SP to SP system where additional information is
passed in the signaling.  The issue is where does that information sit in
the headers (existing or new <gag>) and how does the CUA display it.
Beyond that it becomes more complicated and I think that given the general
public policy concerns, developing incremental solutions can work within
existing framework and after all right now the vast majority of existing
SIP interconnection for voice in NA is directly interconnected and may not
use BGP routing at all.

Mandated solutions for data validation and signing are needed but given
the complexity of the infrastructure necessary to deploy such solutions
mandating signing in the CNIT charter would unacceptably delay progress.

>
>(3) Better caller name information that allows parties other than the
>carrier to assert additional information.

RS>  Yes.  But ptionally. But right now the originating carrier has the
principal business relationship with the calling party that can be
leveraged.  There are several ideas being kicked around for that including
RFC 7095.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 12 Jun 2015 11:49:52 -0400

Henning is right. No one is forcing anything. Existing anonymous calling
protections still apply.

Again my point is that is a great many cases Interconnected SIP between NA
carriers are covered by other security mechanisms.

Right now your Facetime session is totally in the clear. My concern is we
end up going down the rat hole of trying to create perfect end to end
security nothing will get done.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Jun 2015 09:28:22 -0700

One possible extra bit is that we need to know WHO signed.  That could be easy (identity in a cert for the signature), but it’s a requirement.

I still want an optional confidence value, because the source is often not authoritative.

If we’re thinking we’re using the existing display name, and coming up with a way to sign it, then, like stir, the termination side can decide what it wants to do if it gets a display name but no signature.  The sender has the option to provide the name or not, and provide the signature or not.

We COULD consider a new header that would contain the name encrypted for a destination TN (To:).  That would afford privacy to the name to middle boxes that we would not have today with display name.  I would not be opposed to that.  This would work like the offline stir proposal, where the sender obtains the public key of the recipient and encrypts the name for the recipient.

Brian

> On Jun 12, 2015, at 8:49 AM, Richard Shockey <[email-masked]> wrote:
> 
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 12 Jun 2015 12:47:56 -0400

Rich,

I'm probably not following this right, so bear with me.  In the current paradigm the calling party's name isn't sent in the call request message, right?  But you're proposing that it should be (or optionally could be, whatever).  Doesn't that open up the possibility Mr. Farrell suggested, that some entity that's in the path of the call request message can "see" something he previously could not?

Note that "existing anonymous calling protections" apply to the presentation of information to the user, not necessarily to carriage of information across the network.  The FROM header may be anonymized when the calling user requests privacy, for example, but the P-Asserted-Identity header will not.  So if we were to use the display name in the P-A-ID to carry the calling party name asserted by the originating network, that name would (unless we encrypt it) be "visible" to any network element on the path of the INVITE.  

tim

-----Original Message-----
From: cnit [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Friday, June 12, 2015 10:50 AM
To: Stephen Farrell; Henning Schulzrinne; [email-masked]; [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Henning is right. No one is forcing anything. Existing anonymous calling protections still apply.

Again my point is that is a great many cases Interconnected SIP between NA carriers are covered by other security mechanisms.

Right now your Facetime session is totally in the clear. My concern is we end up going down the rat hole of trying to create perfect end to end security nothing will get done.

On 6/12/15, 10:17 AM, "Stephen Farrell" <[email-masked]> wrote:

>Privacy issues could also arise if a middlebox could now see sensitive 
>information that it previously could not see. I think that is 
>independent of whether disclosure is desired by either of the 
>endpoints.
>
>S.
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 12 Jun 2015 12:56:26 -0400

Who would assign the confidence value?  If it's assigned by the entity that operates the calling name database, why would it ever be less than the highest possible value?  If it's set by some other entity, on what basis do they determine the value they assign?  It seems like we're going to stumble over business issues.

Tim

-----Original Message-----
From: cnit [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Friday, June 12, 2015 11:28 AM
To: Richard Shockey
Cc: [email-masked]; Henning Schulzrinne; [email-masked]; Stephen Farrell
Subject: Re: [cnit] CNIT Charter bashing..

Brian

> Again my point is that is a great many cases Interconnected SIP 
> between NA carriers are covered by other security mechanisms.
> 
> Right now your Facetime session is totally in the clear. My concern is 
> we end up going down the rat hole of trying to create perfect end to 
> end security nothing will get done.
> 
> 
> 
>>> issues don't seem to arise. They would only arise if there was 
>>> forced disclosure; I don't think anybody is proposing that.
>> 
>> sensitive information that it previously could not see. I think that 
>> is independent of whether disclosure is desired by either of the 
>> endpoints.
>> 
>> S.
>>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Jun 2015 10:51:12 -0700

Yes, it would be assigned by the entity that signed the name.

It’s not true that it would always be the highest possible value.  If the entity that provided it did that, the receiving entity might not believe it, and choose to use an alternative name source (or at least check another service to see what it thought).  Modern systems that collect names subject user data with verification sources that are getting very accurate, but those services have scoring systems that don’t result in black/white results.  Older systems blithely accept whatever the customer says, and those are not accurate.  Some services have something simpler, like the name has to match a credit card name, but we know those are pretty spoofable these days.  Real systems use external verification services that provide scores for this kind of thing.

I’m simply proposing that we allow an optional confidence, in the range of 0-100, and that it be part of the data signed by the data provider.  No one has to send it, no one has to look at it.  But it represents what is state of the art these days on asserting names and I think it’s valuable.

Brian
> On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) <[email-masked]> wrote:
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 12 Jun 2015 15:21:21 -0400

I guess as long as the derivation of the name (who is asserting it to be a valid representation of the caller, and from where did they get it) is clear to the receiving network, I guess this is OK.  I still have my doubts whether such a value will prove useful, given that its computation is not standardized.  But in some contexts, it might.

Tim

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, June 12, 2015 12:51 PM
To: Dwight, Timothy M (Tim)
Cc: Richard Shockey; [email-masked]; Henning Schulzrinne; [email-masked]; Stephen Farrell
Subject: Re: [cnit] CNIT Charter bashing..

Brian
>> Right now your Facetime session is totally in the clear. My concern 
>> is we end up going down the rat hole of trying to create perfect end 
>> to end security nothing will get done.
>> 
>> 
>>

---

From: Richard Shockey <[email-masked]>
Date: Fri, 12 Jun 2015 15:58:16 -0400

On 6/12/15, 12:47 PM, "Dwight, Timothy M (Tim)"
<[email-masked]> wrote:

>Rich,
>
>I'm probably not following this right, so bear with me.  In the current
>paradigm the calling party's name isn't sent in the call request message,
>right? 

You know how it works in SS7. If SIP is used the verbose CNAM (15
character ASCII) data can be carried in either the From field or P-A
though its my understanding that P-A is typically preferred. There is
another proposal we have seen that could carry the verbose data in
CALL-INFO as well.

> But you're proposing that it should be (or optionally could be,
>whatever). 

Could be..

> Doesn't that open up the possibility Mr. Farrell suggested, that some
>entity that's in the path of the call request message can "see" something
>he previously could not?

Possibly if normal BGP routing is done vs big yellow fiber optic cable.
There are multiple interconnection models here some use classic IP routing
others don¹t. The use case I would want to protect is the one where the
security layer is lower on the stack or the reference to A-CNAM or PII
would be by URI reference where the originating SP could apply normal
HTTPS security mechanism for retrieval etc.  This would certainly apply to
the 7095 JSON vcard object.

>
>Note that "existing anonymous calling protections" apply to the
>presentation of information to the user, not necessarily to carriage of
>information across the network.  The FROM header may be anonymized when
>the calling user requests privacy, for example, but the
>P-Asserted-Identity header will not

Yes but that is a policy issue that needs to be worked out.

>.  So if we were to use the display name in the P-A-ID to carry the
>calling party name asserted by the originating network, that name would
>(unless we encrypt it) be "visible" to any network element on the path of
>the INVITE.  

Or available by reference as the terminating SBC does the look up Šoh
between the first and second ring :-)

>Again my point is that is a great many cases Interconnected SIP between
>NA carriers are covered by other security mechanisms.
>

---

From: Richard Shockey <[email-masked]>
Date: Fri, 12 Jun 2015 17:22:25 -0400

Yes Tim.  Thank you very very much. You cut to the chase of the problem
here.  Its not technology its policy and no matter how you end up looking
at this its National Policy.

KISS I just want to define the CNIT object and SIP headers and NOTHING
ELSE.  IF this should progress in the IETF that needs to be understood.

That said and this is not the carrier business case mailing list.  We all
know the problem has advanced to the point of degrading the value
proposition of the realtime communications service in North America. I’ve
argued endlessly in talks that “Protect what you have” makes sense and as
Henning correctly points out there is a business case for adding value
here to SIP based realtime communications across all the access platforms
including VoLTE and definitely enterprise and there is a real and
important Public Safety component here as well.

We know how this should work.  My Doctor wants to talk to me ASAP about my
medical test results. She wants to display to me that she is exactly who
she says she is and that should be possible so I don’t instantly drop the
call to voice mail or worse.  Her office is served by VZ my mobile is
served by ATT. My ATT VoLTE CUA should be able to trust…by multiple means
(including big yellow optical cable) that the INVITE is actually coming
from VZ.  I see some data on my phone etc I run out of what ever room I’m
in and take the call because I trust the SIP session.

BTW this is equally relevant if the call is initiated by Fairfax County
Public safety.

<begin non relevant rant>

We are trying to protect a 150+ Billion dollar business for SP’s which
represents voice across all the access platforms. I’m not going to support
third party business issues. We all want point to point video and it can
work if we can display who the heck is calling.

OTT is not a issue. Believe me. Get the Telegeography data on OTT
penetration in NA and its stunning once N America went to near flat rate
on voice the threat subsided. OK margins got shot but so did OPEX on
transport.  Our European friends are totally insane.  They are still
addicted to the drug of calling party pays and insane translation costs
then whine to the EU Commission about WhatsAPP etc. They need rehab.

That said our Congresscritter friends are one bunch of pissed off puppies
and at some point they will do some really really stupid if we don’t come
up with a plan. 

On 6/12/15, 4:42 PM, "Dwight, Timothy M (Tim)"
<[email-masked]> wrote:

>Yes, it's a business issue.  Brian wants the protocols to allow him to
>insert an unverifiable advertisement that his data is "good".
>
>If allowing this moves us forward, fine.  There's always some noise in
>the system.  But if this becomes a big topic of debate we need to take it
>out.  It's clearly not essential, and probably not even useful.
>
>Tim
>
>
>From: Richard Shockey [mailto:[email-masked]]
>Sent: Friday, June 12, 2015 3:01 PM
>On 6/12/15, 12:56 PM, "Dwight, Timothy M (Tim)"
>>Who would assign the confidence value?
>
>Tinker bellŠ.the tooth fairy. :-)
>
>This could get really ugly and spawn endless lawsuits but its a
>reasonable idea if someone has a appropriate bayesian algorithm to apply
>to this at the terminating SBC.
>
>
>>If it's assigned by the entity that operates the calling name database,
>>why would it ever be less than the highest possible value?  If it's set
>>by some other entity, on what basis do they determine the value they
>>assign?  It seems like we're going to stumble over business issues.
>>
>>Tim
>>
>>
>>One possible extra bit is that we need to know WHO signed.  That could
>>be easy (identity in a cert for the signature), but it¹s a requirement.
>>
>>If we¹re thinking we¹re using the existing display name, and coming up
>>with a way to sign it, then, like stir, the termination side can decide
>>what it wants to do if it gets a display name but no signature.  The
>>sender has the option to provide the name or not, and provide the
>>signature or not.
>>
>>We COULD consider a new header that would contain the name encrypted
>>for a destination TN (To:).  That would afford privacy to the name to
>>middle boxes that we would not have today with display name.  I would
>>not be opposed to that.  This would work like the offline stir
>>proposal, where the sender obtains the public key of the recipient and
>>encrypts the name for the recipient.
>>
>>Brian
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jun 2015 22:28:25 +0000

Today's CNAM display has three problems:

(1) It is unclear to the recipient how the data got inserted and by whom. There is no realistic way for the callee to find out - good luck calling your phone company consumer support line and asking about CNAM database dips.

(2) The caller has no idea what will be shown to any given called party - depending on the destination CNAM service, it could be the correct name, nothing, just "Florida", or maybe the name of the person who had the same number six months ago and hopefully didn't sell adult entertainment.

(3) For some numbers, bad actors can insert any random information they choose, again with problem #1.

Even unsigned SIP display or Call-Info information, with some modicum of common behavior among carriers, will address all three problems, even if not perfectly, then most of the time. I may have no idea what validation Verizon uses to assure that their customers are indeed John Smith, but at least I know that I can tell who created the entry. A lawyer will know where to address the cease&desist letter if needed.

________________________________________
From: Dwight, Timothy M (Tim) [[email-masked]]
Sent: Friday, June 12, 2015 3:21 PM
To: Brian Rosen
Cc: Richard Shockey; [email-masked]; Henning Schulzrinne; [email-masked]; Stephen Farrell
Subject: RE: [cnit] CNIT Charter bashing..

Tim

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Friday, June 12, 2015 12:51 PM
To: Dwight, Timothy M (Tim)
Cc: Richard Shockey; [email-masked]; Henning Schulzrinne; [email-masked]; Stephen Farrell
Subject: Re: [cnit] CNIT Charter bashing..

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jun 2015 22:39:26 +0000

We have gone around that issue a few times, I think. Without trying to rehash the arguments, I think the value is completely meaningless to the recipient. The value is currently used within a closed environment - company A uses a validation service V and presumably gets a good sense of what "70" means and whether that value is sufficiently high to do whatever they need to do (extend credit, open an account, show tax return information). When company B receives this information, it is completely meaningless to that recipient, as the value will depend on what information the customer A provided, whether A used V, W or X for validation and when this information was validated. Does 70 mean that 70% of the customers with that type of information are indeed who they claim to be? Or just that the person answered 7 out of 10 questions correctly?

Thus, this information is meant to be interpreted within a particular context, and taking it out of this context renders it meaningless.

Thus, unless these issues can be addressed, we would be conveying information that pretends to be accurate, but is just noise. Brian, you repeat the same idea, but never address the issues that get raised again and again. This is not helpful.

We also now know from the IRS tax return debacle that knowledge-based authentication varies in quality. I'm sure whoever got access to the tax returns scored a 100 on whatever questions the web site asked...

________________________________________
From: Brian Rosen [[email-masked]]
Sent: Friday, June 12, 2015 1:51 PM
To: Dwight, Timothy M (Tim)
Cc: Richard Shockey; [email-masked]; Henning Schulzrinne; [email-masked]; Stephen Farrell
Subject: Re: [cnit] CNIT Charter bashing..

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jun 2015 22:47:56 +0000

I suspect there could be cases where a caller objects to the disclosure to intermediate entities; they clearly should have the option of not including the name information, either on a call-by-call or global basis. I'm guessing that this is a rare case; for the entities most reliant on caller name information, namely entities that cannot count on being in the address book of the called party, they usually have semi-public telephone numbers, so that the mapping to the name is essentially public. As I noted, as long as roughly the same information is in-band as out-of-band today, every single carrier can already look up CNAM information if they are so inclined. Thus, I'm not quite following how this makes things worse. (The difference is that today, I can look up CNAM information for any phone number, even if the entity never called me. In-band delivery would obviate the need for CNAM databases, so it would seem to make things better, not worse.)

The latter point obviously only applies to countries with CNAM; as long as the opt-in/opt-out nature is preserved, this seems more like a disclosure issue ("your name is visible to your carrier and, if the carrier is too lazy to implement SIP over TLS, any national intelligence agency that happens to be watching that fiber").

________________________________________
From: Dwight, Timothy M (Tim) [[email-masked]]
Sent: Friday, June 12, 2015 12:47 PM
To: Richard Shockey; Stephen Farrell; Henning Schulzrinne; [email-masked]; [email-masked]
Subject: RE: [cnit] CNIT Charter bashing..

Rich,

tim

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jun 2015 22:51:15 +0000

Once numbers have public (STIR) keys, the sender should indeed be able to encrypt the information without creating a new infrastructure for distributing keys, and the destination carrier can decrypt. (I think I'm just amplifying slightly what you are saying, not disagreeing.)

Agreed on "who", although this may be implicit in some cases (e.g., if signed by the number-signing entity).

________________________________________
From: Brian Rosen [[email-masked]]
Sent: Friday, June 12, 2015 12:28 PM
To: Richard Shockey
Cc: Stephen Farrell; Henning Schulzrinne; [email-masked]; [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Jun 2015 16:20:59 -0700

Okay so, I’ll try to give you meaningful answers to the questions you raise.  I believe I’ve done this before.
> On Jun 12, 2015, at 3:39 PM, Henning Schulzrinne <[email-masked]> wrote:
> 
> We have gone around that issue a few times, I think. Without trying to rehash the arguments, I think the value is completely meaningless to the recipient. The value is currently used within a closed environment - company A uses a validation service V and presumably gets a good sense of what "70" means and whether that value is sufficiently high to do whatever they need to do (extend credit, open an account, show tax return information).

Actually, many companies have multiple sources of information, and use more than one of them some times.  Since there is zero standardization, the company has to know how to interpret the results, but since there are a relatively small number of sources, it works fine.  When dealing with a simple score, you have some kind of a scaling factor that normalizes them.  That idea will work just fine here.  The receiving end will have scaling factors for the sources it encounters.  There may even be services that provide scaling factors.  You accumulate and adjust your scaling factors based on the observations you have on the data.  Here, it might be customer complaints, or UIs that have “report errors” buttons, or periodic secondary validation systems.  My company could pretty easily calculate a pretty good set of scaling factors given a large enough sample of historical call data with scores based on the databases we have.  So can others.  If a new scoring service shows up, it might have a pretty low scaling factor until you build up enough data to raise it.  

So the termination SP, or device, will apply a scale to the score based on the identity of the source of the score and use that to determine what to do.   Depending on the device, it could change the appearance of the name depending on the scaled score, or it could subject the name to alternative validation, or use a third party name source.

> When company B receives this information, it is completely meaningless to that recipient, as the value will depend on what information the customer A provided, whether A used V, W or X for validation and when this information was validated. Does 70 mean that 70% of the customers with that type of information are indeed who they claim to be? Or just that the person answered 7 out of 10 questions correctly?
The score can be defined as a confidence percentage.  70 means there is a 70% chance the name is correct.  The scoring service is free to use any method it wants to come up with the score.  
> Thus, this information is meant to be interpreted within a particular context, and taking it out of this context renders it meaningless.
The context is very well defined - what is the name of the entity placing the call?  The score is the confidence we have in the answer provided.

> Thus, unless these issues can be addressed, we would be conveying information that pretends to be accurate, but is just noise. Brian, you repeat the same idea, but never address the issues that get…
No, it’s the exact opposite.  When you send just a name without a score, you are pretending it’s 100% accurate, and that is clearly wrong.  When you send a score, you acknowledge that the data is not 100% accurate, and you show what your confidence is in the information you are providing.  Since we have a lot of experience, we know how to get quality scoring.  What we can’t do is mandate a good scoring methodology or source, so we have to have some more complications like the scaling factor.  But we do that now, because there is lots of competition for data, having more than one source is common and yet we know they don’t all provide the same quality of data.  So we deal with that.

> 
> We also now know from the IRS tax return debacle that knowledge-based authentication varies in quality. I'm sure whoever got access to the tax returns scored a 100 on whatever questions the web site asked…
Certainly.  Any scoring system can be gamed.  Nothing is perfect.  But just saying the guy’s name is Clark Kent is no where near as useful as saying that Name Scoring Service Inc says there is an 93% probability that the guy’s name is Clark Kent.  If someone says 100%, you should not believe them.

These kinds of systems are common.  We use them in lots of environments.  We know how they work.  We know what their limitations are.  This isn’t rocket science, but it is data science.  Why are you so skeptical of proven systems?

Brian

---

From: Richard Shockey <[email-masked]>
Date: Fri, 12 Jun 2015 21:29:29 -0400

Henning the biggest issue is that any form of advanced CNAM display is not
currently applicable to the the mobile access devices. Which are now
finally over 50% of the NANP even if you consider BYOD in the enterprise.
Yea that is another use case.

Hence the issue with Apple. This is ultimately a problem with that will
have to be coordinated with US GSMA or GSMA generally.

Or IMHO with the the 8th floor on 12th st. It really is a jawboning use.
Tom needs to call Tim Cook or Larry Page and make the ask.

I do reject Brians pretense here. Given the IETF context perfection is
actually the enemy of deployment.

I want a charter that is simple and clear.  Header and object. Period.  If
that is impossible then Š..

Its time the AD¹s decide.

‹ 
Richard Shockey
Shockey Consulting LLC

On 6/12/15, 6:28 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>(1) It is unclear to the recipient how the data got inserted and by whom.
>There is no realistic way for the callee to find out - good luck calling
>your phone company consumer support line and asking about CNAM database
>dips.
>
>(2) The caller has no idea what will be shown to any given called party -
>depending on the destination CNAM service, it could be the correct name,
>nothing, just "Florida", or maybe the name of the person who had the same
>number six months ago and hopefully didn't sell adult entertainment.
>
>Even unsigned SIP display or Call-Info information, with some modicum of
>common behavior among carriers, will address all three problems, even if
>not perfectly, then most of the time. I may have no idea what validation
>Verizon uses to assure that their customers are indeed John Smith, but at
>least I know that I can tell who created the entry. A lawyer will know
>where to address the cease&desist letter if needed.
>
>I guess as long as the derivation of the name (who is asserting it to be
>a valid representation of the caller, and from where did they get it) is
>clear to the receiving network, I guess this is OK.  I still have my
>doubts whether such a value will prove useful, given that its computation
>is not standardized.  But in some contexts, it might.
>
>Tim
>
>
>It¹s not true that it would always be the highest possible value.  If the
>entity that provided it did that, the receiving entity might not believe
>it, and choose to use an alternative name source (or at least check
>another service to see what it thought).  Modern systems that collect
>names subject user data with verification sources that are getting very
>accurate, but those services have scoring systems that don¹t result in
>black/white results.  Older systems blithely accept whatever the customer
>says, and those are not accurate.  Some services have something simpler,
>like the name has to match a credit card name, but we know those are
>pretty spoofable these days.  Real systems use external verification
>services that provide scores for this kind of thing.
>
>I¹m simply proposing that we allow an optional confidence, in the range
>of 0-100, and that it be part of the data signed by the data provider.
>No one has to send it, no one has to look at it.  But it represents what
>is state of the art these days on asserting names and I think it¹s
>valuable.
>
>Brian
>> Who would assign the confidence value?  If it's assigned by the entity
>>that operates the calling name database, why would it ever be less than
>>the highest possible value?  If it's set by some other entity, on what
>>basis do they determine the value they assign?  It seems like we're
>>going to stumble over business issues.
>>
>> Tim
>>
>>
>>not be opposed to that.  This would work like the offline stir proposal,
>>where the sender obtains the public key of the recipient and encrypts
>>the name for the recipient.
>>
>> Brian
>>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Sat, 13 Jun 2015 18:47:35 -0400

Henning,

I appreciate, and mostly agree with, your comments below.  Please see additional thoughts inline.

tim

-----Original Message-----
From: cnit [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Friday, June 12, 2015 5:28 PM
To: Dwight, Timothy M (Tim); Brian Rosen
Cc: [email-masked]; [email-masked]; Stephen Farrell; Richard Shockey
Subject: Re: [cnit] CNIT Charter bashing..

[tmd] People do call their service provider's "support line" about issues with calling name, and we do help them.  Nobody will claim that that's easy though.  The information can be obtained in various ways from various sources.  The proliferation of non-authoritative calling name databases sometimes leads to disputes over "whose data is correct", which can delay resolution.

[tmd] I agree that the caller generally cannot know what will be shown to any given called party.  I don't agree that this is always a function of the _destination_ CNAM service, though.  In "conventional" CNAM services (ref: GR-1188) the terminating exchange does a TCAP query to obtain calling name information from the originating network.  The result is in that case dictated by the caller's service provider, since it is they (or a 3rd party to whom they subcontract this service) who reply to the query. 

[tmd] That would be a clever lawyer.  As noted above, when incorrect calling name information is being displayed, it can be difficult to determine why.  I wish it were as simple as "if the caller is a Verizon customer, it must be Verizon's fault".  But it isn't.  Consider customers A and B.  A is a Verizon customer.  B is a CarrierB customer.  CarrierB uses 3rdPartyCnamLike service to obtain calling name information for incoming calls.  When A calls B, the name displayed to B doesn't come from Verizon. 

Tim

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Friday, June 12, 2015 12:51 PM
To: Dwight, Timothy M (Tim)
Cc: Richard Shockey; [email-masked]; Henning Schulzrinne; [email-masked]; Stephen Farrell
Subject: Re: [cnit] CNIT Charter bashing..

It's not true that it would always be the highest possible value.  If the entity that provided it did that, the receiving entity might not believe it, and choose to use an alternative name source (or at least check another service to see what it thought).  Modern systems that collect names subject user data with verification sources that are getting very accurate, but those services have scoring systems that don't result in black/white results.  Older systems blithely accept whatever the customer says, and those are not accurate.  Some services have something simpler, like the name has to match a credit card name, but we know those are pretty spoofable these days.  Real systems use external verification services that provide scores for this kind of thing.

I'm simply proposing that we allow an optional confidence, in the range of 0-100, and that it be part of the data signed by the data provider.  No one has to send it, no one has to look at it.  But it represents what is state of the art these days on asserting names and I think it's valuable.

Brian
> One possible extra bit is that we need to know WHO signed.  That could be easy (identity in a cert for the signature), but it's a requirement.
>
> If we're thinking we're using the existing display name, and coming up with a way to sign it, then, like stir, the termination side can decide what it wants to do if it gets a display name but no signature.  The sender has the option to provide the name or not, and provide the signature or not.
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Sat, 13 Jun 2015 19:09:33 -0400

Henning,

As you may know, there are controls over disclosure of calling name data that mirror those which govern disclosure of calling number.  In the conventional CNAM model these are attributes in the LIDB.  These need either to be explicitly changed (e.g., if consumers no longer need these protections) or replicated into whatever alternative model this group develops.  Since it's not up to the IETF to determine public policy, I guess we're best off trying to replicate the existing functionality.

Intuitively I agree that an entity with a "public" or "semi-public" telephone number would probably not object to their name being displayed to people they call.  But that is not necessarily the case.  All I can say for sure is that today consumers have control over this (you can mark your name "public" or "private" in the LIDB;  and you can ask that name presentation be "tied" to number presentation - i.e., if you can ask that presentation of your name be blocked if presentation of your number is blocked, either permanently or call-by-call).

Similarly I can't say for sure whether anyone would object to their name being visible to networks or network elements to which it is not visible today.  I think if we propose to increase its visibility the onus is on us to be sure.

Tim

-----Original Message-----
From: cnit [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Friday, June 12, 2015 5:48 PM
To: Dwight, Timothy M (Tim); [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Rich,

tim

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 14 Jun 2015 13:50:11 +0000

With in-band delivery, controlling delivery of information should, in theory, be easier, since we no longer rely on third-party services.

My guess is that many PBX and SIP trunking systems rely on companies like OpenCNAM or the other service providers listed at http://www.voip-info.org/wiki/view/CNAM . They currently can't provide call-by-call privacy, only a global "always on"/"always off" setting.

Thus, I think we all agree that callers should have control, either permanently or maybe call-by-call, on whether to disclose caller name information, and callers should be aware that this information may be visible to carriers in the call path. (In many cases, that's likely to be just the caller's carrier and the destination carrier, but things obviously sometimes get more complicated in rural call scenarios or if there's a separate LD carrier.)

Henning
________________________________________
From: Dwight, Timothy M (Tim) [[email-masked]]
Sent: Saturday, June 13, 2015 7:09 PM
To: Henning Schulzrinne; [email-masked]
Subject: RE: [cnit] CNIT Charter bashing..

Henning,

Tim

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 14 Jun 2015 13:55:28 +0000

Just to clarify: For the lawyer remark, I meant the future in-band scenario. I agree that under the current mode of operation, you'd need a private detective, not a lawyer. In the in-band case, carrier B would have no incentive to use a third-party service, so a call from a number assigned to Verizon would always have caller name from Verizon (however they created it).

The idea is that you don't need perfect validation if you can easily track down who inserted the information. If the information is maliciously wrong, it becomes feasible to use non-technical means to correct the information. 

Henning

________________________________________
From: Dwight, Timothy M (Tim) [[email-masked]]
Sent: Saturday, June 13, 2015 6:47 PM
To: Henning Schulzrinne; Brian Rosen
Cc: [email-masked]; [email-masked]; Stephen Farrell; Richard Shockey
Subject: RE: [cnit] CNIT Charter bashing..

Henning,

tim

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 14 Jun 2015 14:01:44 +0000

The VoLTE/IMS experts listening probably know this better, but judging from some quick Googling of sample VoLTE call flows, SIP display name information is already part of the IMS/VoLTE standards, so model #1 (NNI) shouldn't be that hard, and we can then build on that, as you hint at.

I suspect we all agree that the barrier to entry should be minimal. We can discuss, for example, whether a by-reference or by-value mechanism is better, or we need both.

________________________________________
From: Richard Shockey [[email-masked]]
Sent: Friday, June 12, 2015 9:29 PM
To: Henning Schulzrinne; Dwight, Timothy M (Tim); Brian Rosen
Cc: [email-masked]; [email-masked]; Stephen Farrell; Ben Campbell
Subject: Re: [cnit] CNIT Charter bashing..

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 14 Jun 2015 14:25:18 +0000

I just don't see this working. It gets worse in the way you describe since there's no way for the the recipient to know what secret mix of tools the originating carrier used, when they changed that secret mix and what the number may mean. Also, unlike in the fraud case, where you have a good underlying ground truth (the bad guy stole your money or turns out to be a deadbeat), with caller name information, the recipient has no good way to check whether a score of 70 corresponds to anything. They'll only know if somebody asserts "FBI" and it turns out that the caller doesn't have a badge.

>From a consumer perspective, this is completely useless. What would I do with a score of 70? Is that good or bad? Is it only good if the call is from AT&T (which I won't know) but bad if it's from TMobile?

I think we need more than assertion and "magic happens" here...

More constructively, I think the model that provides broad indications of how the information was derived is helpful:

(1) self-asserted ("123 Bogus Street, Anytown" is acceptable)

(2) validated (i.e., the company name exists and any other information, such as street address, exists), but no guarantee that the caller is entitled to that name

(3) billing information (the name and location corresponds to a billing or credit card record)

(4) verified (using third party services such as KBA, above whatever threshold the originator considers good enough)

This corresponds very roughly to the current web model - (1) is somebody's gmail address or Google-hosted blog; (2) is a dedicated domain name with plausible whois information; (3) is a standard TLS cert and (4) is an EV cert.

Henning

________________________________________
From: Brian Rosen [[email-masked]]
Sent: Friday, June 12, 2015 7:20 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Brian

---

From: Richard Shockey <[email-masked]>
Date: Sun, 14 Jun 2015 10:21:19 -0400

Tim I hope we can remember that the use cases here are not always driven
by consumer to consumer.  B2B is equally important though the rules get
tricky for B2C.

On 6/13/15, 7:09 PM, "Dwight, Timothy M (Tim)"
<[email-masked]> wrote:

>Henning,
>
>As you may know, there are controls over disclosure of calling name data
>that mirror those which govern disclosure of calling number.  In the
>conventional CNAM model these are attributes in the LIDB.  These need
>either to be explicitly changed (e.g., if consumers no longer need these
>protections) or replicated into whatever alternative model this group
>develops.  Since it's not up to the IETF to determine public policy, I
>guess we're best off trying to replicate the existing functionality.

Hense my insistence on first simply looking at what headers are used here
in order to maintain some interoperability.  There are enough folks around
here in DC that can deal with the policy questions. I certainly understand
the concern about privacy issues. Its actually one of the more interesting
parts of the issue.  Who¹s privacy are we trying to protect.  The privacy
of the calling party or the privacy of the called party? Should the called
party have some rights to know who is calling?

Or are we doomed to voice mail hell for the rest of eternity or worse.
   
http://www.bloomberg.com/news/articles/2014-12-22/coca-cola-disconnects-voi
ce-mail-at-headquarters

IMHO this development is directly the result of the industry not focusing
on the underlying problem in the current service definition.  BTW I don¹t
agree with all of the conclusions here. In fact there is some anecdotal
evidence that that point to point voice communications is experiencing a
small resurgence since real time voice communications does not leave a
³paper trail² nor subject to fat thumb ³send all² buttons and voice
communications are not generally recorded except by the NSA for course.

>
>Intuitively I agree that an entity with a "public" or "semi-public"
>telephone number would probably not object to their name being displayed
>to people they call.  But that is not necessarily the case.  All I can
>say for sure is that today consumers have control over this (you can mark
>your name "public" or "private" in the LIDB;  and you can ask that name
>presentation be "tied" to number presentation - i.e., if you can ask that
>presentation of your name be blocked if presentation of your number is
>blocked, either permanently or call-by-call).
>
>Similarly I can't say for sure whether anyone would object to their name
>being visible to networks or network elements to which it is not visible
>today.  I think if we propose to increase its visibility the onus is on
>us to be sure.
>
>Tim
>
>
>I suspect there could be cases where a caller objects to the disclosure
>to intermediate entities; they clearly should have the option of not
>including the name information, either on a call-by-call or global basis.
>I'm guessing that this is a rare case; for the entities most reliant on
>caller name information, namely entities that cannot count on being in
>the address book of the called party, they usually have semi-public
>telephone numbers, so that the mapping to the name is essentially public.
>As I noted, as long as roughly the same information is in-band as
>out-of-band today, every single carrier can already look up CNAM
>information if they are so inclined. Thus, I'm not quite following how
>this makes things worse. (The difference is that today, I can look up
>CNAM information for any phone number, even if the entity never called
>me. In-band delivery would obviate the need for CNAM databases, so it
>would seem to make things better, not worse.)
>
>The latter point obviously only applies to countries with CNAM; as long
>as the opt-in/opt-out nature is preserved, this seems more like a
>disclosure issue ("your name is visible to your carrier and, if the
>carrier is too lazy to implement SIP over TLS, any national intelligence
>agency that happens to be watching that fiber").
>
>To: Richard Shockey; Stephen Farrell; Henning Schulzrinne;
>[email-masked]; [email-masked]
>right?  But you're proposing that it should be (or optionally could be,
>whatever).  Doesn't that open up the possibility Mr. Farrell suggested,
>that some entity that's in the path of the call request message can "see"
>something he previously could not?
>
>P-Asserted-Identity header will not.  So if we were to use the display
>name in the P-A-ID to carry the calling party name asserted by the
>originating network, that name would (unless we encrypt it) be "visible"
>to any network element on the path of the INVITE.
>
>tim
>
>

---

From: Richard Shockey <[email-masked]>
Date: Sun, 14 Jun 2015 10:35:43 -0400

On 6/14/15, 10:01 AM, "Henning Schulzrinne" <[email-masked]>
wrote:

>The VoLTE/IMS experts listening probably know this better, but judging
>from some quick Googling of sample VoLTE call flows, SIP display name
>information is already part of the IMS/VoLTE standards, so model #1 (NNI)
>shouldn't be that hard, and we can then build on that, as you hint at.

Agreed.  Its how the mobile CUA deals with the INVITE that contains the
data it that is very unclear to me.  That is ultimately a issue 3GPP GSMA
or US GSMA should know something about.

>
>I suspect we all agree that the barrier to entry should be minimal. We
>can discuss, for example, whether a by-reference or by-value mechanism is
>better, or we need both.

Agreed.

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Sun, 14 Jun 2015 13:58:20 -0400

Henning,

I'm not sure 'carrier B' would in the "in-band case" have no incentive to use a 3rd party service.  It might be that the 3rd party service provides additional information and/or is considered more trustworthy than whoever provided the in-band information.  We can (and I hope will) change the incentives.  I think it would be a reasonable objective to carry whatever content is deemed "necessary" to serve the public, in-band.  If people want to operate databases full of calling party's cat pictures, and Carrier B wants to provide this to their customer (or allow their customer to obtain it themselves, e.g., provide them a link to it) that's all OK with me.

I agree with you about the importance of being able to know unambiguously, who inserted the information.

Tim

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Sunday, June 14, 2015 8:55 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]
Subject: RE: [cnit] CNIT Charter bashing..

Henning

Henning,

tim

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Sun, 14 Jun 2015 14:21:38 -0400

This sounds right.  3GPP IMS standards support both user-provided identity information (the FROM header) and network-provided identity information (the P-Asserted-Identity header).  Both can optionally include a display-name.  

The Originating Identity Presentation (OIP) and Originating Identity Restriction (OIR) services generally govern presentation to the called user of the network-provided identity information.  The network may or may not also restrict (in the case of OIR) presentation of the user-provided identity information.

tim

-----Original Message-----
From: cnit [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Sunday, June 14, 2015 9:02 AM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Henning the biggest issue is that any form of advanced CNAM display is not currently applicable to the the mobile access devices. Which are now finally over 50% of the NANP even if you consider BYOD in the enterprise.
Yea that is another use case.

Hence the issue with Apple. This is ultimately a problem with that will have to be coordinated with US GSMA or GSMA generally.

I do reject Brians pretense here. Given the IETF context perfection is actually the enemy of deployment.

I want a charter that is simple and clear.  Header and object. Period.  If that is impossible then Š..

---

From: Eric Burger <[email-masked]>
Date: Sun, 14 Jun 2015 14:42:03 -0400

[changing the subject to be meaningful, kind of like a CNAM…]

I fully agree with Henning here for two reasons.

Reason #1: the point of CNIT, STIR, MODERN, et al. is we are not dooming ourselves to simply do IP versions of SS7. We already have that. My expectation is for 99% of the use of CNIT, the calling name will be inserted by the end user equipment (enterprise PBX or SIP phones) or the carrier service provider (mobile, wireline replacement, broadband cable telephony, etc.).

What do we do with the 1% of calls that will come from non-service provider endpoints? E.g., what if you had an open source Foo Fone? The easy answer would be to say you are in a self-signed certificate bind. If you want your name to pop up correctly, pay for a service that will vouch for you. However, the IETF does not mandate business models. So, one could envision some sort of PGP-like web of trust. However, that is on the signing of the name, NOT on the number-to-name translation. Let us be realistic: if I cannot trust the veracity of the name, I cannot trust the veracity of the calling number, so all bets are off anyway.

I thus see zero need for or value from some third-party number-to-name translation service. This simply replicates all of the evils of the current system when the players are NOT trying to be evil, but only stupid. As an example, see Tim’s emails on how CNAM does not work today at:
https://mailarchive.ietf.org/arch/msg/cnit/D7JeNaGHOjHJAaFi2jeT2Y_C1oA
Now imagine the third-party number-to-name translation service DOES want to be evil. Yuck!

Nothing in what I have seen in CNIT would *prevent* third-party number validation services or third-party number-to-name services from offering such services. They work today: at my endpoint, *I* decide to do another dip with these services. However, I see nothing in CNIT that would be sensible for such a service to be in the *signaling* path.

Reason #2: if the user or the user’s service provider is in control of inserting the signed calling name, then all of the user privacy arguments evaporate. Who cares that a real calling name, THAT THE USER WANTS DISPLAYED, gets sent in the signaling path? First of all, it is up to the USER to send the information. Second, yes, this is different than today’s North American SS7 configuration. SURPRISE! We are talking SIP, not SS7. We can do whatever we want. Given we have thirty years of knowing sending only the number and later asking for the name is hopelessly broken, why would we want to replicate that? Remember the mantra: “User Control is Good."

It is unquestionably true that we are making it easier for amateurs to find out the calling name by sniffing the signaling. This says they have access to unencrypted signaling (probably already a problem). Moreover, it is saying that they have access to the signaling and yet they DO NOT have any access to a number-to-name translation data base. I would offer the latter is a 0.0000000001% probability. If they have the sophistication to crack sips (OK, not too hard, but not trivial), they have access to any of the public number-to-name data bases out there.

If we do want to protect from, for example, nation-states, we could encrypt the name itself with the public key of the called party. If someone is that paranoid, they will not mind the setup penalty in the signaling. I doubt anyone would use it, but if that is what it takes to get chartered, I’ve got students who can write an I-D that nobody will use but will get a publication ;-)

> On Jun 14, 2015, at 10:25 AM, Henning Schulzrinne <[email-masked]> wrote:
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 15 Jun 2015 13:26:43 -0400

A couple of clarifications suggested to me offline.  First a quote from TS 24.607, which defines the Originating Identity Presentation (OIP) and Originating Identity Restriction (OIR) services:

   "The OIP service provides the terminating user with the possibility of receiving trusted (i.e. network provided) identity information in order to identify the originating user"

Observations:

a) it generally addresses network -provided identity (which normally translates to the content of a P-Asserted-Identity header; though it allows as a network option to remove P-A-ID and convey calling identity information in the From header).

b) It does not specify how the terminating network obtains the identity information it "asserts" to the UE.  The most obvious place would be from the P-Asserted-Identity header it received in the request.  But I don't see any prohibition against other things, e.g., of the terminating network modifying the information it received in P-A-ID.  One thought relevant to this discussion is that the terminating network might do a CNAM query using the calling number from a P-A-ID header extracted from the request as key, and put the result in the display-name field of a P-Asserted-Identity header it sends to the UE.  As far as I can tell the 3GPP spec does not prohibit such things.

c) it talks about providing the terminating user with the _possibility_ of receiving calling user identity information.  Which I believe means that it governs network behavior but not the behavior of the terminating device.  The network may for example communicate a calling name in a P-A-ID header, but the device might display instead the name it has in its contact list for that number.  Or the device might obtain a name from another source (e.g., query some name service), or display no name at all.  Point being, the 3GPP spec does not mandate what the human actually sees.

tim

-----Original Message-----
From: Dwight, Timothy M (Tim) 
Sent: Sunday, June 14, 2015 1:22 PM
To: 'Henning Schulzrinne'; Richard Shockey
Cc: [email-masked]
Subject: RE: [cnit] CNIT Charter bashing..

tim

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 15 Jun 2015 21:39:03 +0000

I've said this before, but I think in many cases, the name is less important than some verifiable property. For example, apparently some durable medical equipment fraudsters use the display name MEDCARE. From a quick trademark search, there actually is a legitimate business with that name (Medcare Discount Pharmacy), but validating the name does not always protect against user confusion. A flag that shows that this is a legitimate, licensed pharmacy would be more useful and that type of validation can be provided by any number of third-party entities. The number of such categories is very small since the number of businesses that need to be state/federally-licensed and that care about validation (your nail salon or florist may need a license but is unlikely to care about tagging their phone calls) isn't that large.

Thus, validating names is useful, but 100% accuracy validation may be very difficult to achieve (given the need for brevity and practical limitations of sources of information in the age of IRS KBA bypass.) For example, I have a credit card that uses a non-state-registered name (xyz consulting) and a billing address validation might accept this as legitimate.

As a side note, I recently used Dun&Bradstreet to access and modify my corporate (DUNS) record for a small entity I run. For their KBA, all I needed to know was the registered address, landline phone number and the last two digits of the SSN, plus some "did you ever use some-ridiculous-first-name" question. Not very confidence-inducing. Given that this small business has no credit history, this is not surprising - there just isn't much to work with that isn't listed on the certificate of incorporation.

Practically speaking, most names aren't worth faking. There seems little benefit to pretending to be Joe's Pizza or Adam Smith if you're not, except for pranks ("Did you just order 100 anchovy pizzas?"). Thus, protecting high-value names is likely more productive, such as those of government agencies, utilities/carriers or financial institutions. 

________________________________________
From: cnit [[email-masked]] on behalf of Eric Burger [[email-masked]]
Sent: Sunday, June 14, 2015 2:42 PM
To: [email-masked]
Subject: [cnit] Who says I am me? I say it is me. I have no reason to trust     you.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 15 Jun 2015 22:11:26 +0000

Agreed that the terminating carrier can provide added value, e.g., by linking to other information. You could imagine mapping numbers to BBB information, or databases or registered charities, or Yelp... I am somewhat surprised that this isn't happening already more broadly.

________________________________________
From: Dwight, Timothy M (Tim) [[email-masked]]
Sent: Sunday, June 14, 2015 1:58 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [cnit] CNIT Charter bashing..

Henning,

Tim

---

From: Richard Shockey <[email-masked]>
Date: Mon, 15 Jun 2015 18:32:07 -0400

Tim Henning .. This is uniquely timely and important because the SIP Forum
is at this moment attempting to revise its SIPConnect Recommendation for
PBX / hosted to SSP interface where the data may be originated by the
enterprise and it needs to be treated in some way by the NNI. (hopefully
maybe not stripped if its seen in the FROM or P-AI)

Its a complication but not insurmountable. It clearly shows we need to
rethink the charter and look at some baby steps vs demanding that all the
STIR like mechanisms be in place before there is progress.

‹ 
Richard Shockey
Shockey Consulting LLC

On 6/15/15, 6:11 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>Agreed that the terminating carrier can provide added value, e.g., by
>linking to other information. You could imagine mapping numbers to BBB
>information, or databases or registered charities, or Yelp... I am
>somewhat surprised that this isn't happening already more broadly.
>
>I'm not sure 'carrier B' would in the "in-band case" have no incentive to
>use a 3rd party service.  It might be that the 3rd party service provides
>additional information and/or is considered more trustworthy than whoever
>provided the in-band information.  We can (and I hope will) change the
>incentives.  I think it would be a reasonable objective to carry whatever
>content is deemed "necessary" to serve the public, in-band.  If people
>want to operate databases full of calling party's cat pictures, and
>Carrier B wants to provide this to their customer (or allow their
>customer to obtain it themselves, e.g., provide them a link to it) that's
>all OK with me.
>
>I agree with you about the importance of being able to know
>unambiguously, who inserted the information.
>
>Tim
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Tue, 16 Jun 2015 11:52:32 -0400

Henning,

What you describe sounds like it would facilitate robocalls - appending to a call from a random pharmacy, an advertisement on behalf of the caller.  I'm sure that's not what you intend.

I think it would be more useful to the called party to know that the call is from a specific pharmacy with which they are familiar.  If they're familiar with it they already know what type of entity it is.

Tim

-----Original Message-----
From: cnit [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Monday, June 15, 2015 4:39 PM
To: Eric Burger; [email-masked]
Subject: Re: [cnit] Who says I am me? I say it is me. I have no reason to trust you.

[changing the subject to be meaningful, kind of like a CNAM...]

I thus see zero need for or value from some third-party number-to-name translation service. This simply replicates all of the evils of the current system when the players are NOT trying to be evil, but only stupid. As an example, see Tim's emails on how CNAM does not work today at:
https://mailarchive.ietf.org/arch/msg/cnit/D7JeNaGHOjHJAaFi2jeT2Y_C1oA
Now imagine the third-party number-to-name translation service DOES want to be evil. Yuck!

Reason #2: if the user or the user's service provider is in control of inserting the signed calling name, then all of the user privacy arguments evaporate. Who cares that a real calling name, THAT THE USER WANTS DISPLAYED, gets sent in the signaling path? First of all, it is up to the USER to send the information. Second, yes, this is different than today's North American SS7 configuration. SURPRISE! We are talking SIP, not SS7. We can do whatever we want. Given we have thirty years of knowing sending only the number and later asking for the name is hopelessly broken, why would we want to replicate that? Remember the mantra: "User Control is Good."

If we do want to protect from, for example, nation-states, we could encrypt the name itself with the public key of the called party. If someone is that paranoid, they will not mind the setup penalty in the signaling. I doubt anyone would use it, but if that is what it takes to get chartered, I've got students who can write an I-D that nobody will use but will get a publication ;-)

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 29 Jun 2015 23:47:31 +0000

It's not clear to me that we need any STIR-like mechanisms to be in place
before embarking on CNIT. What I've basically written in to STIR is an
extension field that CNIT could use to hook into the signature. All it
would require is that CNIT create a specification (as currently written, a
Standards Track RFC) that designates what the field(s) that will be
signed, and then the necessary procedures and so on.

Fundamentally I agree that hooking CNIT into STIR will only provide part
of a solution. There are going to be cases when the entity that originates
(or signs) SIP signaling is not going to be the right party to attest to
the proper display name for a user.

Architecturally, what I'd probably prefer is to think about this work as
designing a small, but somewhat extensible block of information which
someone could sign. Small enough that it could fit in a SIP message, and
be signed there by hooking into the STIR extension field. But also
something that could be carried by an external protocol for those cases
when the STIR signer might not be the authority on the display name. Maybe
the STIR signer would fetch it via that external protocol, and then pass
along the signature of the authority from whom they acquired it, in
addition to signing it themselves. Or maybe the recipient would use the
external protocol if there is no STIR hook. If we build a system with
roughly those qualities, and focus more on the info block than on how it
gets transported necessarily, I think we'll do some valuable work.

Jon Peterson
Neustar, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Jun 2015 02:28:13 +0000

I was wondering if it would work to have two STIR headers, with the second binding the phone number to the display name (and other SIP headers, to prevent replay). Obviously, downstream validating parties have to have a reason to trust the signing party, but that always seems to be the case when you don't have the number signer as the implied originating carrier computing the signature.

________________________________________
From: Peterson, Jon [[email-masked]]
Sent: Monday, June 29, 2015 7:47 PM
To: Richard Shockey; Henning Schulzrinne; Dwight, Timothy M (Tim)
Cc: [email-masked]
Subject: Re: [cnit] CNIT Charter bashing..

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 30 Jun 2015 04:45:29 +0000

This is more or less how I imagine it could work.

Not to get ahead of a draft I haven't submitted yet, but basically the
revised rfc4474bis text creates an optional Identity-Extension header
which allows future specifications to define a new field or set of fields
that a signature would fall over. The main Identity signature also covers
the contents of Identity-Extension, when it is present. So, if CNIT were
to decide to just use the From display-name, a new Identity-Extension
header signature over the display-name alone could be defined. If CNIT
defines a new header, like hypothetically a CNIT-Name header, then the
contents of the Identity-Extension header field could be a signature over
CNIT-Name. This seemed like the way we could accommodate the broadest set
of design choices for CNIT.

So effectively this mechanism should allow a separate header that binds
the signature over the phone number to the signature in the
Identity-Extension header, which in turn would cover the name. If it turns
out that a hypothetical CNIT-Name header contains its own signature from
the authority attesting for the display name, separate from the rfc4474bis
sig, then either that could be signed via the Identity-Extension header or
not. That also covers cases where the originator of a SIP request isn't
the authority for the number (like, if the request enters the SIP world
through a PSTN gateway).

Jon Peterson
Neustar, Inc.

On 6/29/15, 7:28 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>I was wondering if it would work to have two STIR headers, with the
>second binding the phone number to the display name (and other SIP
>headers, to prevent replay). Obviously, downstream validating parties
>have to have a reason to trust the signing party, but that always seems
>to be the case when you don't have the number signer as the implied
>originating carrier computing the signature.
>