Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework)

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Aug 2013 16:02:24 +0000

In general, given that many users base their decision on how to treat a call on the textual caller ID, rather than the number, I think this is indeed a problem we should think about, even if the result is to punt this to another effort. As per Steve's comment, there is value of tying the provider of the name to the textual identifier, as it reduces the threat of DigiNotar-style attacks. 

I have a number of hypotheses:

(1) Validating the names of commercial entities is more important than that of individuals. (Individuals also sometimes have legitimate reasons to provide partial information. For example, it's been a long tradition, whether justified by evidence or not, for households of single women to use initials rather than full first names in directory listings and thus also CLID.) The numbers shown to the public are likely public knowledge, so concerns about keeping them secret may be lower.

(2) Legitimate businesses have an incentive to provide correct information that can be validated. The incentives of other parties are, shall we say, mixed.

(3) Financial and other entities at significant risk of fraud are probably reasonably-well resourced and represented in databases such as the Dun&Bradstreet registry or government databases.

(4) Whitelisting is easier than blacklisting.

(5) It is helpful if name abusers can be located quickly, as that facilitates legal remedies.

Thus, to get to the solution space, I can see three directions that might be productive:

(1) Provide an indication by a trusted party (such as the terminating provider) as to the provenance of the textual callerID information. This will then allow other tools to provide, for example, some visual indication of the trustworthiness, without the provider having to make that editorial judgment. 

(2) Provide a whois-like mechanism for more extensive information at least equivalent to EV certs, possibly signed by the same key used for numbers, to prevent the CA issues. This would only be available to smartphones (but also case (1)) and is primarily meant to identify commercial identities. I see this as a separate effort; expect to hear more about this shortly. It needs to be cryptographically-coupled with the E.164 mechanism, even if provided by another party such as D&B.

(3) For the SIP display-name case with end-to-end delivery, it would be helpful to have a way to sign both name and number. This doesn't deal with impostors or look-alike names, but other attacks outlined earlier.

As number assignment goes beyond the realm of "few big companies with regulator visitors to the regulators" (in the FCC context, the "blue badge people"), we will face the same or similar whois-type issues that ICANN is dealing with. Fortunately, we have somewhat more local enforcement mechanisms, so the problem may be more tractable.

As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chances that callees will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information.

Henning
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Monday, August 19, 2013 11:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Hadriel,

> ...
>
> We know we can't just trust callerid4u to claim any CNAM it wanted to.  So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them.  This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say).
This aspect of your proposal already raises several concerns in my mind:

- Jane Doe is not a globally unique name, so a called party can't assume that the caller is the Jane Doe that comes to mind

- I strongly doubt that there is a single CA that could (should) be trusted to the identity of every caller in every country. if we have per-country CAs we start getting close to the problems we have in the browser environment.

- As a rule, the best CAs are ones that are authoritative for the attributes for which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally meaningful), and if one tries to tie both attributes into one cert ...

My bottom line is that I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding.

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

---

From: Michael Hammer <[email-masked]>
Date: Mon, 19 Aug 2013 16:14:20 +0000

There is no reason that the digital signature binding a Name to a Number
could not be orthogonal and managed independently from the valid
sender/Number binding.

You could bundle these together, but there may be reasons to keep them
separate.

With names, you are now talking about a registry with personal information
and you may have many folks that do not want their names made public.
I could see this as being more valuable for businesses, and that may be one
or two orders of magnitude fewer entities to manage.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Monday, August 19, 2013 12:02 PM
To: 'Stephen Kent'; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,
Early Homework)

In general, given that many users base their decision on how to treat a call
on the textual caller ID, rather than the number, I think this is indeed a
problem we should think about, even if the result is to punt this to another
effort. As per Steve's comment, there is value of tying the provider of the
name to the textual identifier, as it reduces the threat of DigiNotar-style
attacks. 

(1) Validating the names of commercial entities is more important than that
of individuals. (Individuals also sometimes have legitimate reasons to
provide partial information. For example, it's been a long tradition,
whether justified by evidence or not, for households of single women to use
initials rather than full first names in directory listings and thus also
CLID.) The numbers shown to the public are likely public knowledge, so
concerns about keeping them secret may be lower.

(2) Legitimate businesses have an incentive to provide correct information
that can be validated. The incentives of other parties are, shall we say,
mixed.

(3) Financial and other entities at significant risk of fraud are probably
reasonably-well resourced and represented in databases such as the
Dun&Bradstreet registry or government databases.

(5) It is helpful if name abusers can be located quickly, as that
facilitates legal remedies.

Thus, to get to the solution space, I can see three directions that might be
productive:

(1) Provide an indication by a trusted party (such as the terminating
provider) as to the provenance of the textual callerID information. This
will then allow other tools to provide, for example, some visual indication
of the trustworthiness, without the provider having to make that editorial
judgment. 

(2) Provide a whois-like mechanism for more extensive information at least
equivalent to EV certs, possibly signed by the same key used for numbers, to
prevent the CA issues. This would only be available to smartphones (but also
case (1)) and is primarily meant to identify commercial identities. I see
this as a separate effort; expect to hear more about this shortly. It needs
to be cryptographically-coupled with the E.164 mechanism, even if provided
by another party such as D&B.

(3) For the SIP display-name case with end-to-end delivery, it would be
helpful to have a way to sign both name and number. This doesn't deal with
impostors or look-alike names, but other attacks outlined earlier.

As number assignment goes beyond the realm of "few big companies with
regulator visitors to the regulators" (in the FCC context, the "blue badge
people"), we will face the same or similar whois-type issues that ICANN is
dealing with. Fortunately, we have somewhat more local enforcement
mechanisms, so the problem may be more tractable.

As with number spoofing, I think an achievable goal is that unsigned,
untraceable textual caller ID will be seen as dodgy and increase the chances
that callees will not answer the call (or let it go to voicemail),
increasing the incentive for legitimate call originators to provide
identifying information.

Henning
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Monday, August 19, 2013 11:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Hadriel,

> ...
>
> We know we can't just trust callerid4u to claim any CNAM it wanted to.  So
let's say instead of trusting callerid4u, we designated some common CA to
verify and sign CNAM information for everyone, and everyone has to trust
them.  This CA used various sources of information and verification to
create a "certificate" that said "for this phone number X, the user's name
is Jane Doe", or maybe "for the holder of the private key for this public
key, the user's name is Jane Doe" (which is basically what web certificates
say).
This aspect of your proposal already raises several concerns in my mind:

- Jane Doe is not a globally unique name, so a called party can't assume
that the caller is the Jane Doe that comes to mind

- I strongly doubt that there is a single CA that could (should) be trusted
to the identity of every caller in every country. if we have per-country CAs
we start getting close to the problems we have in the browser environment.

- As a rule, the best CAs are ones that are authoritative for the attributes
for which they vouch. For phone numbers a lot of folks seem confident that
we have the right players to perform this function. For common names, we do
not (until you add a lot of context, which is often not universally
meaningful), and if one tries to tie both attributes into one cert ...

My bottom line is that I don't believe in the web CA model; it has failed.
DANE is a much better approach, becuase it aligns name space management and
public key binding.

Steve

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Aug 2013 16:21:26 +0000

That's why I mentioned third parties, such as (without any implied endorsement, obviously) D&B. The goal is to allow one or more such third parties, but allow the business to tie their E.164 keypair to that registration. That seems relatively simple - if the whois-style information contains a signature block with the same private key that's used for the number, the recipient can easily check that they are connected, without the name database being tied in any organizational way to the E.164 database.

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Monday, August 19, 2013 12:14 PM
To: Henning Schulzrinne; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework)

Mike

-----Original Message-----

Henning
-----Original Message-----

Hadriel,

Steve

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Mon, 19 Aug 2013 16:27:16 +0000

Though I say this with some trepidation, it would seem easier to keep the two together. At least in my world, service providers are the entities who know who a number is assigned to; they are the ultimate sources of CNAM data even if their databases are not queried directly.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Monday, August 19, 2013 12:14 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework)

Mike

-----Original Message-----

Henning
-----Original Message-----

Hadriel,

Steve

---

From: Michael Hammer <[email-masked]>
Date: Mon, 19 Aug 2013 16:42:32 +0000

Understand.  I was mainly asking for the flexibility to manage them
separately if need be.

Be careful what you wish for.  You just might get it.  :)

Mike

-----Original Message-----
From: PFAUTZ, PENN L [mailto:[email-masked]] 
Sent: Monday, August 19, 2013 12:27 PM
To: Michael Hammer; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [stir] Textual caller ID (was Re: Moving from BOF to Charter,
Early Homework)

Though I say this with some trepidation, it would seem easier to keep the
two together. At least in my world, service providers are the entities who
know who a number is assigned to; they are the ultimate sources of CNAM data
even if their databases are not queried directly.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
Michael Hammer

Mike

-----Original Message-----

Henning
-----Original Message-----

Hadriel,

Steve

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 19 Aug 2013 13:12:28 -0400

Remember those databases are already in existence now. Phone companies and
others have the data. A binding of number to "preferred display name"
determined by the number holder as part of the service should be doable.
How or if it is displayed is then the responsibility of the terminating SSP
under appropriate national regulation. 

I agree with Henning here.

"As with number spoofing, I think an achievable goal is that unsigned,
untraceable textual caller ID will be seen as dodgy and increase the chances
that callee will not answer the call (or let it go to voicemail), increasing
the incentive for legitimate call originators to provide identifying
information." 

It would also be nice if the UA could display something more than 15 ASCII
characters, but that is a brand new issue STIR cannot, nor should it, solve.

-----Original Message-----

Mike

-----Original Message-----

Henning
-----Original Message-----

Hadriel,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Aug 2013 13:57:02 -0400

Henning,

> That's why I mentioned third parties, such as (without any implied endorsement, obviously) D&B. The goal is to allow one or more such third parties, but allow the business to tie their E.164 keypai…

D&B was explored as a candidate CA for organizations long ago, in the 
PKI world.
It didn't work out.

In Italy, the chambers of commerce were considered appropriate 
candidates as CAs for businesses, for electronic financial transactions. 
Not sure if that has progressed.

We have several decades of experience in trying to do this, in the PKI 
space, with
the EU having pushed harder than anywhere else.

I agree with your bottom line observation, i.e., assume independence 
from the E.164
database. (I would add, don't expect a great outcome!).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Aug 2013 14:17:27 -0400

Henning,

> (1) Provide an indication by a trusted party (such as the terminating provider) as to the provenance of the textual callerID information. This will then allow other tools to provide, for example, s…
we have provided an ability to include a logo for a CA in X.509 certs 
for many
years. It is (almost?) never used.
> (2) Provide a whois-like mechanism for more extensive information at least equivalent to EV certs, possibly signed by the same key used for numbers, to prevent the CA issues. This would only be ava…
based on many years of experience in the generic PKI arena, paid third 
parties acting as trust providers are problematic. And, EV certs are not 
a great solution, unless you happen
to be a CA getting paid to issue them :-).
> (3) For the SIP display-name case with end-to-end delivery, it would be helpful to have a way to sign both name and number. This doesn't deal with impostors or look-alike names, but other attacks o…
yes, one could bind the two together, perhaps by binding signed 
assertions about
each under a common signature. but I worry about the many, opportunities 
for this
to go south.
> As number assignment goes beyond the realm of "few big companies with regulator visitors to the regulators" (in the FCC context, the "blue badge people"), we will face the same or similar whois-typ…
maybe.
> As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chances that callees will not answer the call (or let it g…
I agree. But, I worry about the contra-positive case too, i.e., any form 
of signed assertion may be interpreted as secure, with predictable, 
adverse consequences.

Let's be modest in our goals for this WG, at least initially.

Steve

---

From: Michael Hammer <[email-masked]>
Date: Mon, 19 Aug 2013 19:24:26 +0000

Catching up on thread.

The touchstone here might be:  Can the phone company be held legally liable
if they supply bad name data?
I don't think that is the case right now.
Your level of trust may vary.  
I'm not sure what we would be going for here.

Mike

-----Original Message-----

Mike

-----Original Message-----

Henning
-----Original Message-----

Hadriel,

Steve

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 20 Aug 2013 08:21:57 +0200

19 aug 2013 kl. 18:02 skrev Henning Schulzrinne <[email-masked]>:

> In general, given that many users base their decision on how to treat a call on the textual caller ID, rather than the number, I think this is indeed a problem we should think about, even if the result is to punt this to another effort.

I really think we have to leave this out-of-scope for the first part of the work. We will end up with character set issues, the need for multiple names in different scripts and multiple persons sharing the same phone number...

I think it's just too big a problem to include if we are in a hurry to find a solution to the primary problem - the trust of the actual caller ID.

/O

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 22 Aug 2013 14:53:38 +0000

> determined by the number holder as part of the service should be doable.

I have not checked into the regulation but as far as I can tell, in Canada end consumers can request whatever they want to be put in this database as long as it is not profane (and reading the white pages, there is some pretty funny stuff ). I have not seen what happens if I request "HSBC Bank" but "Flu Ffy" seems to be OK. 

And this does not even get in to the www.stamford.edu problem ( This organization advertises all over Thailand - check out my photo at http://www.flickr.com/photos/cullenfluffyjennings/9570844196/   I particularly love their truth in advertising tag line of "The Difference is Real" ). 

Given we don't really know how to solve this problem, and we are dealing with the internet where in some countries "Bank of America" may not be the same organization it is in the US and they don't care about US trademark laws, I think we will simply fail on human readable names and instead need to focus on the unique verifiable identifiers and allow other mechanisms to map the unique identifiers to things that make sense to the human user in that users context.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 22 Aug 2013 17:37:28 -0400

Actually, we DO know how to solve most of the problem. We have pretty good
databases that, given enough input, can give you a decent name (i.e. the
real one).  We further could combine a user request with such validation to
allow the kinds of self representation freedom, within limits, that seems
desirable.

There are ways to game any such system, and I would not claim otherwise.
 But you can't dispute the basics that we can provide decent authentication
of name.  The systems we have now could tell you the difference between
stamford and stanford.  They probably would not let you claim Flu Ffy as
your actual name.  They would not let you claim HSBC Bank.

I think your fundamental assumption that we will fail on human readable
names is incorrect, although it will not be as reliable as the calling
telephone number.  Given user interfaces, I think we (at some point) must
deal with human readable names, because we are not going to get people to
only accept calls from people already in their address books, and we are
not going to be able to get humans to recognize a phone number they have
not yet seen.

Brian

On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennings (fluffy) <[email-masked]
> wrote:

> I have not checked into the regulation but as far as I can tell, in Canada
> end consumers can request whatever they want to be put in this database as
> long as it is not profane (and reading the white pages, there is some
> pretty funny stuff ). I have not seen what happens if I request "HSBC Bank"
> but "Flu Ffy" seems to be OK.
>
> And this does not even get in to the www.stamford.edu problem ( This
> organization advertises all over Thailand - check out my photo at
> http://www.flickr.com/photos/cullenfluffyjennings/9570844196/   I
> particularly love their truth in advertising tag line of "The Difference is
> Real" ).
>
> Given we don't really know how to solve this problem, and we are dealing
> with the internet where in some countries "Bank of America" may not be the
> same organization it is in the US and they don't care about US trademark
> laws, I think we will simply fail on human readable names and instead need
> to focus on the unique verifiable identifiers and allow other mechanisms to
> map the unique identifiers to things that make sense to the human user in
> that users context.
>
>
>
>
>
>

---

From: Cary FitzGerald <[email-masked]>
Date: Thu, 22 Aug 2013 17:23:54 -0700

The problem of finding a database to look up a number doesn't seem like an (IETF) standards issue, at best it's for a best practices, for both reverse lookups and UX.

In this chain:

	me <- my provider <- white/pink/red providers <- shady organization with a gateway or a SIP robot

money flows from right to left, and from right to left.  The business practices of the providers in the middle limit the losses they are willing to tolerate.  Given enough motivation, the forensic tools exist to find the rightmost and the leftmost organizations to pay the bill.  Someone's paying the freight, even if it's fractions of cents per minute.  So at some level, there is a chain of trust that is as reliable as a credit card transaction (at the least!).

However, as you move across this chain (let's focus on the left to right direction), there is no corresponding moral or legal responsibility or practice to validate identity.  Sometimes the chain of trust is transparent, sometimes it's not.  From time to time, trust holds in ways that are at odds with called partys' common sense, hence the stamford/stanford and Flu Fly...HSBC Bank continuum.

We can describe a system of identity with E.164 or the like; we can talk about how to make those identities to access mechanisms; we can develop ways to map the access to the databases, and we can secure parts of that chain from various attacks, but we can't give meaning to the data that it doesn't have.  That's a social/regulatory/business practice problem.

I am not arguing to do nothing, but I think that we should clearly classify the issues and not try to force a technological solution to a business problem.  My worry for stir is that a lot of the technological solutions feel like solutions for other related problems this community has run up against in the past.

Cary.

On Aug 22, 2013, at 2:37 PM, Brian Rosen wrote:

> Actually, we DO know how to solve most of the problem. We have pretty good databases that, given enough input, can give you a decent name (i.e. the real one).  We further could combine a user request with such validation to allow the kinds of self representation freedom, within limits, that seems desirable.  
> 
> There are ways to game any such system, and I would not claim otherwise.  But you can't dispute the basics that we can provide decent authentication of name.  The systems we have now could tell you the difference between stamford and stanford.  They probably would not let you claim Flu Ffy as your actual name.  They would not let you claim HSBC Bank.
> 
> I think your fundamental assumption that we will fail on human readable names is incorrect, although it will not be as reliable as the calling telephone number.  Given user interfaces, I think we (at some point) must deal with human readable names, because we are not going to get people to only accept calls from people already in their address books, and we are not going to be able to get humans to recognize a phone number they have not yet seen.
> 
> Brian
> 
> 
> On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennings (fluffy) <[email-masked]> wrote:
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 23 Aug 2013 10:00:40 -0400

Look at the thread again.  Tim proposed that the paradigm for caller name
be changed so that the origination side used existing display name, and
P-A-ID to send caller name through signaling.  If that was the paradigm,
then the recipient wants some sort of assurance the name is genuine,
assurance obtained on the origination side and sent through the signaling
to the termination side.  That is the standardization required.

This changes the flow of money.  Today, the termination side pays for a
data dip, either to an originating SP database or some independent
database.  The proposal to to change that so that there is no specific
charge, it just comes on the wire.   TNSTAFL, it's in the general peering
relationship costs.

On Thu, Aug 22, 2013 at 8:23 PM, Cary FitzGerald <[email-masked]>wrote:

> The problem of finding a database to look up a number doesn't seem like an
> (IETF) standards issue, at best it's for a best practices, for both reverse
> lookups and UX.
>
>
> In this chain:
>
> money flows from right to left, and from right to left.  The business
> practices of the providers in the middle limit the losses they are willing
> to tolerate.  Given enough motivation, the forensic tools exist to find the
> rightmost and the leftmost organizations to pay the bill.  Someone's paying
> the freight, even if it's fractions of cents per minute.  So at some level,
> there is a chain of trust that is as reliable as a credit card transaction
> (at the least!).
>
> However, as you move across this chain (let's focus on the left to right
> direction), there is no corresponding moral or legal responsibility or
> practice to validate identity.  Sometimes the chain of trust is
> transparent, sometimes it's not.  From time to time, trust holds in ways
> that are at odds with called partys' common sense, hence the
> stamford/stanford and Flu Fly...HSBC Bank continuum.
>
> We can describe a system of identity with E.164 or the like; we can talk
> about how to make those identities to access mechanisms; we can develop
> ways to map the access to the databases, and we can secure parts of that
> chain from various attacks, but we can't give meaning to the data that it
> doesn't have.  That's a social/regulatory/business practice problem.
>
> I am not arguing to do nothing, but I think that we should clearly
> classify the issues and not try to force a technological solution to a
> business problem.  My worry for stir is that a lot of the technological
> solutions feel like solutions for other related problems this community has
> run up against in the past.
>
> Cary.
>
>> I have not checked into the regulation but as far as I can tell, in
>> Canada end consumers can request whatever they want to be put in this
>> database as long as it is not profane (and reading the white pages, there
>> is some pretty funny stuff ). I have not seen what happens if I request
>> "HSBC Bank" but "Flu Ffy" seems to be OK.
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Aug 2013 11:16:20 -0400

On Aug 23, 2013, at 10:00 AM, Brian Rosen <[email-masked]> wrote:

> Look at the thread again.  Tim proposed that the paradigm for caller name be changed so that the origination side used existing display name, and P-A-ID to send caller name through signaling.  If that was the paradigm, then the recipient wants some sort of assurance the name is genuine, assurance obtained on the origination side and sent through the signaling to the termination side.  That is the standardization required.

Someday maybe - but it's not in the charter for STIR, and not in scope for now.  Nothing prevents folks from working on how to accomplish it somehow, and re-charter or create another WG for that someday.  But right now it's not our focus in this STIR WG-to-be, afaik.

> This changes the flow of money.  Today, the termination side pays for a data dip, either to an originating SP database or some independent database.  The proposal to to change that so that there is no specific charge, it just comes on the wire.   TNSTAFL, it's in the general peering relationship costs.

The problem though, as has been pointed out by many folks over the past decade we've been talking about this stuff, is that the money flow pays for delivery of calls.  The 'pink' originator and transit carriers are paid by the sender to deliver phone calls, so the monetary incentive model works against us.  We can't blindly trust them to put in legitimate names.

Even if we used a 'secured' form of PAI header (something like http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01), it would ultimately require a reputation system; and deciding another carrier is not trustworthy and thus stripping their calling names is very problematic.  It would undoubtedly result in lawsuits and anti-competitive FTC complaints, for example.

With calling numbers we think we have a way to fix it, both technologically and pragmatically, and in such a way that it doesn't disrupt the flow of money+incentive nor open up anti-trade issues.  For calling names the problem is much harder, and we haven't figured out a technological and pragmatic way to fix it.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Fri, 23 Aug 2013 13:22:38 -0400

The idea is that you get a 3rd party to provide the level of assurance,
hoping that the number of such services would be small and thus the
trustworhlyness of them being understood widely.  The termination end can
decide if it trusts that third party, and, if necessary, use an alternative
service if it doesn't.  The reason to keep discussing this in stir is to
emphasize that the mechanism may need to carry some other data, like the
assurance on the name, in addition to what we're already discussing.

On Fri, Aug 23, 2013 at 11:16 AM, Hadriel Kaplan
<[email-masked]>wrote:

> > Look at the thread again.  Tim proposed that the paradigm for caller
> name be changed so that the origination side used existing display name,
> and P-A-ID to send caller name through signaling.  If that was the
> paradigm, then the recipient wants some sort of assurance the name is
> genuine, assurance obtained on the origination side and sent through the
> signaling to the termination side.  That is the standardization required.
>
> Someday maybe - but it's not in the charter for STIR, and not in scope for
> now.  Nothing prevents folks from working on how to accomplish it somehow,
> and re-charter or create another WG for that someday.  But right now it's
> not our focus in this STIR WG-to-be, afaik.
>
>
> The problem though, as has been pointed out by many folks over the past
> decade we've been talking about this stuff, is that the money flow pays for
> delivery of calls.  The 'pink' originator and transit carriers are paid by
> the sender to deliver phone calls, so the monetary incentive model works
> against us.  We can't blindly trust them to put in legitimate names.
>
> Even if we used a 'secured' form of PAI header (something like
> http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01), it
> would ultimately require a reputation system; and deciding another carrier
> is not trustworthy and thus stripping their calling names is very
> problematic.  It would undoubtedly result in lawsuits and anti-competitive
> FTC complaints, for example.
>
> With calling numbers we think we have a way to fix it, both
> technologically and pragmatically, and in such a way that it doesn't
> disrupt the flow of money+incentive nor open up anti-trade issues.  For
> calling names the problem is much harder, and we haven't figured out a
> technological and pragmatic way to fix it.
>
> -hadriel
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Aug 2013 14:44:29 -0400

On Aug 23, 2013, at 1:22 PM, Brian Rosen <[email-masked]> wrote:

> The idea is that you get a 3rd party to provide the level of assurance, hoping that the number of such services would be small and thus the trustworhlyness of them being understood widely.  The termination end can decide if it trusts that third party, and, if necessary, use an alternative service if it doesn't.  

We have that already today: just in the USA there are over a dozen LIDB providers, and even more CNAM DB providers.  The validity of the data in them varies, but they're essentially the "3rd party" model.

> The reason to keep discussing this in stir is to emphasize that the mechanism may need to carry some other data, like the assurance on the name, in addition to what we're already discussing. 

That's a good point.

One of the things we talked about originally was that a valid calling number was a precursor to calling name, because the name lookup is based on the calling number for the key.  So I think for the current LIDB/CNAM models the currently-proposed STIR in-band data is sufficient (or at least I was thinking that way when I wrote the draft-IKES mechanism).

Regardless, my concern is I can easily foresee a calling name discussion knocking us off-the-tracks very quickly.  For example I expect the feature-creep to begin with including various other forms of name identifiers, such as email or social-site-based names, and then getting into the need for an IdP model, SSO/SAML/OpenID, OAuth, etc.  Or we start debating how to distinguish legitimate financial banks from blood banks and sperm banks; or how users receiving just the string "Fidelity" disambiguate when they get calls from: Fidelity Investments, Fidelity National Financial, Fidelity National Information Services, USS Fidelity, Fidelity Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all legal, separate entities in the US)

I don't really know how to prevent such ratholes, but maybe we need a separate mailing list for the name discussions (i.e. for a research/design-team) to separate that stuff out and keep this one focused on the charter's scope?

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Fri, 23 Aug 2013 15:24:51 -0400

The only think we have now is a way for the termination end to use an
alternate source of names.  In the scheme we're discussing, the primary
mechanism DOES NOT use a database queried by TN at the termination, except
when it doesn't like the trustworthlyness of the originator's validation
service, or when there is no name, or no validation - i.e. fall back.

The primary mechanism would be to use the display name in SIP, with a new
validation thingie in the stir signature, from a trusted 3rd party
(hopefully one of only a few of them).  We don't do that today.

Let me emphasize:

All I want out of stir is a way to extend the signature to cover whatever
we come up with.  That "whatever" can be done in a recharter of stir,
later, or it could be done in a separate WG, as long as we can extend the
signature to cover other stuff.

I think another mail list is a good idea, but that means we have to come up
with another acronym!

Brian

On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan
<[email-masked]>wrote:

> service if it doesn't.
> We have that already today: just in the USA there are over a dozen LIDB
> providers, and even more CNAM DB providers.  The validity of the data in
> them varies, but they're essentially the "3rd party" model.
>
>
> > The reason to keep discussing this in stir is to emphasize that the
> mechanism may need to carry some other data, like the assurance on the
> name, in addition to what we're already discussing.
>
> That's a good point.
>
> One of the things we talked about originally was that a valid calling
> number was a precursor to calling name, because the name lookup is based on
> the calling number for the key.  So I think for the current LIDB/CNAM
> models the currently-proposed STIR in-band data is sufficient (or at least
> I was thinking that way when I wrote the draft-IKES mechanism).
>
> Regardless, my concern is I can easily foresee a calling name discussion
> knocking us off-the-tracks very quickly.  For example I expect the
> feature-creep to begin with including various other forms of name
> identifiers, such as email or social-site-based names, and then getting
> into the need for an IdP model, SSO/SAML/OpenID, OAuth, etc.  Or we start
> debating how to distinguish legitimate financial banks from blood banks and
> sperm banks; or how users receiving just the string "Fidelity" disambiguate
> when they get calls from: Fidelity Investments, Fidelity National
> Financial, Fidelity National Information Services, USS Fidelity, Fidelity
> Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN,
> Fidelity WFID, or Fidelity Township NJ. (all legal, separate entities in
> the US)
>
> I don't really know how to prevent such ratholes, but maybe we need a
> separate mailing list for the name discussions (i.e. for a
> research/design-team) to separate that stuff out and keep this one focused
> on the charter's scope?
>
> -hadriel
>
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 23 Aug 2013 15:38:11 -0400

Henning previously suggested what I understood to be a "database of names" into which entities concerned that their name might be spoofed, could register themselves.  Banks for example.  The idea was that to validate a "calling name" you could look up that name in this database, and get in return a list of phone numbers they've registered as numbers they use to call people.  You could then check to see if the [validated] calling number was on that list.

That seems to me to have at least one hole, though.  Duplicate names.  You can't disallow them because in the real world it happens.  But maybe in the process of registering your name, you get a unique identifier.  And that identifier gets signaled in some new parameter, in addition to the textual name.  The validation function could then look up this identifier to determine (a) what name should be displayed, and (b) whether the [validated] calling number is registered as associated with that name.  

Brian is correct that I suggested the validation function might be on the originating side of the call; which would require some way to carry the result and the entity claiming to have produced that result, in the signaling message.

That doesn't of course prevent the terminating network validating it again, if the entity claiming to have performed that validation, isn't deemed trustworthy. 

I'm happy to take the topic of how best to authenticate calling name, to another list.  But if the initial STIR work specifies signaling enhancements, I would like to see them include a way to convey the result of a calling name validation performed somewhere upstream.  Nothing about how to do the validation [yet].  Let the folks who elect to post to this other list, work on that.  Just a container for the result.

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Friday, August 23, 2013 1:44 PM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework)

That's a good point.

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 23 Aug 2013 15:40:10 -0400

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Friday, August 23, 2013 2:25 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework)

The only think we have now is a way for the termination end to use an alternate source of names.  In the scheme we're discussing, the primary mechanism DOES NOT use a database queried by TN at the termination, except when it doesn't like the trustworthlyness of the originator's validation service, or when there is no name, or no validation - i.e. fall back.

The primary mechanism would be to use the display name in SIP, with a new validation thingie in the stir signature, from a trusted 3rd party (hopefully one of only a few of them).  We don't do that today.

Let me emphasize:

All I want out of stir is a way to extend the signature to cover whatever we come up with.  That "whatever" can be done in a recharter of stir, later, or it could be done in a separate WG, as long as we can extend the signature to cover other stuff.

I think another mail list is a good idea, but that means we have to come up with another acronym!

Brian

On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

That's a good point.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 23 Aug 2013 19:55:10 +0000

Brian,

Your fatal flaw is that the trust of the signature must be based in the
authority over the thing to be signed.

With E.164 numbers we have some hope of achieving that; with all others
probably no chance in hell to do so.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Friday, August 23, 2013 3:25 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,
Early Homework)

Let me emphasize:

All I want out of stir is a way to extend the signature to cover whatever we
come up with.  That "whatever" can be done in a recharter of stir, later, or
it could be done in a separate WG, as long as we can extend the signature to
cover other stuff.

Brian

On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan <[email-masked]>
wrote:

> The reason to keep discussing this in stir is to emphasize that the
mechanism may need to carry some other data, like the assurance on the name,
in addition to what we're already discussing.

That's a good point.

One of the things we talked about originally was that a valid calling number
was a precursor to calling name, because the name lookup is based on the
calling number for the key.  So I think for the current LIDB/CNAM models the
currently-proposed STIR in-band data is sufficient (or at least I was
thinking that way when I wrote the draft-IKES mechanism).

Regardless, my concern is I can easily foresee a calling name discussion
knocking us off-the-tracks very quickly.  For example I expect the
feature-creep to begin with including various other forms of name
identifiers, such as email or social-site-based names, and then getting into
the need for an IdP model, SSO/SAML/OpenID, OAuth, etc.  Or we start
debating how to distinguish legitimate financial banks from blood banks and
sperm banks; or how users receiving just the string "Fidelity" disambiguate
when they get calls from: Fidelity Investments, Fidelity National Financial,
Fidelity National Information Services, USS Fidelity, Fidelity Records,
Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID,
or Fidelity Township NJ. (all legal, separate entities in the US)

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 23 Aug 2013 19:57:59 +0000

p.s.  maybe something that is SHAKEN but not STIR'd.  J

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Hammer
Sent: Friday, August 23, 2013 3:55 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,
Early Homework)

Brian,

Mike

Let me emphasize:

Brian

That's a good point.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 23 Aug 2013 16:20:04 -0400

Let me emphasize:

[RS> ] 

[RS> ] WARNING WARNING DANGER WILL ROBINSON!!  OCEAN BOILING ALERT!  Its
perfectly reasonable to postulate that the signing can ultimately extend
cover "other things". That was Richard Barnes's excellent point. We dont
have an approved charter yet and we're talking extensions? 

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 23 Aug 2013 16:22:22 -0400

VODKA .  MARTINI has been used. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Hammer
Sent: Friday, August 23, 2013 3:58 PM
To: Michael Hammer; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,
Early Homework)

p.s.  maybe something that is SHAKEN but not STIR'd.  :)

Mike

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Friday, August 23, 2013 3:55 PM
To: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,
Early Homework)

Brian,

Mike

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] <mailto:[mailto:[email-masked]]>  On
Behalf Of Brian Rosen
Sent: Friday, August 23, 2013 3:25 PM
To: Hadriel Kaplan
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,
Early Homework)

Let me emphasize:

Brian

On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan <[email-masked]
<mailto:[email-masked]> > wrote:

That's a good point.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Aug 2013 16:33:37 -0400

> The only think we have now is a way for the termination end to use an alternate source of names.  In the scheme we're discussing, the primary mechanism DOES NOT use a database queried by TN at the…

I'm not sure which "scheme we're discussing" you're referring to: the calling number validation scheme, or the calling name validation scheme?  For the calling number validation scheme, it does use a database queried by the TN at the termination: the one to retrieve the public key or cert from.  CNAM likewise queries a database by the TN, at the termination.  From the verifier's perspective, they could either be the exact same physical database being queried, or separate physical databases.  Or the public-key database entry could identify which 3rd party identity provider to go query for calling name, but that subsequent query could still be made using the validated TN, or a hash of one, for example.

> The primary mechanism would be to use the display name in SIP, with a new validation thingie in the stir signature, from a trusted 3rd party (hopefully one of only a few of them).  We don't do that…

That's presuming a particular solution, and I don't know what the details of it are so I'm not sure I follow you.  If the solution you're thinking of is to use the same private key to also sign the display-name (ie, include the display-name in the STIR signature), I don't think you actually need to do that.  If the solution you're thinking of is to use a separate private-key to sign the display-name, that's a bigger deal.

> All I want out of stir is a way to extend the signature to cover whatever we come up with.  That "whatever" can be done in a recharter of stir, later, or it could be done in a separate WG, as long…

For me, it depends on how that would be accomplished.  From a protocol spec perspective sure, we could always extend a published RFC in the future, so long as there's ABNF extensibility and so on.  But presumably you'd want some way for the initial STIR work to be forwards-compatible with that extension, such that the initial STIR signature continues to "work" even if it reaches a verifier that doesn't support a new calling name verification thing.  Right?

> I think another mail list is a good idea, but that means we have to come up with another acronym!

haven't thought about it much.  Here're some off the top of my head:
Secure Caller-Associated Name - SCAN
Reputable Identity Name Greeting - RING  (which would make for a STIRRING solution)
Calling Name Identity Communication - CNIC  (pronounced Scenic)
Stir-Transported Reputable Identity Name Generator - STRING
Assured Source Caller Identity Information - ASCII  ;)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Aug 2013 16:43:20 -0400

On 8/23/13 3:57 PM, Michael Hammer wrote:
> p.s.  maybe something that is SHAKEN but not STIR’d. J

But actually we expect something that is both STIRed *and* SHAKEN.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Aug 2013 16:50:09 -0400

So this will give the callee, at most:
- the E.164 of the caller, and a signature by somebody vouching for it
- a name vouched for by the same signer

And with the delegation being proposed, the signer may be the assignee 
of the specific number. (E.g., the doctor.) The doctor can make his name 
be "First National Bank" if he wants to.

So all this really gets you is accountability: if somebody starts using 
bogus names in an objectionable way then it will be possible to hold the 
signer responsible. This is definitely better than nothing. It may be 
the best we can achieve. But I doubt it is what users expect.

	Thanks,
	Paul

On 8/23/13 3:24 PM, Brian Rosen wrote:
> mechanism DOES NOT use a database queried by TN at the termination,
> except when it doesn't like the trustworthlyness of the originator's
> validation service, or when there is no name, or no validation - i.e.
> fall back.
>
> The primary mechanism would be to use the display name in SIP, with a
> new validation thingie in the stir signature, from a trusted 3rd party
> All I want out of stir is a way to extend the signature to cover
> whatever we come up with.  That "whatever" can be done in a recharter of
> stir, later, or it could be done in a separate WG, as long as we can
> extend the signature to cover other stuff.
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     <mailto:[email-masked]>> wrote:
>
>      > The idea is that you get a 3rd party to provide the level of
>     assurance, hoping that the number of such services would be small
>     and thus the trustworhlyness of them being understood widely.  The
>     termination end can decide if it trusts that third party, and, if
>     necessary, use an alternative service if it doesn't.
>
>     We have that already today: just in the USA there are over a dozen
>     LIDB providers, and even more CNAM DB providers.  The validity of
>     the data in them varies, but they're essentially the "3rd party" model.
>
>
>      > The reason to keep discussing this in stir is to emphasize that
>     the mechanism may need to carry some other data, like the assurance
>     on the name, in addition to what we're already discussing.
>
>     That's a good point.
>
>     One of the things we talked about originally was that a valid
>     calling number was a precursor to calling name, because the name
>     lookup is based on the calling number for the key.  So I think for
>     the current LIDB/CNAM models the currently-proposed STIR in-band
>     data is sufficient (or at least I was thinking that way when I wrote
>     the draft-IKES mechanism).
>
>     Regardless, my concern is I can easily foresee a calling name
>     discussion knocking us off-the-tracks very quickly.  For example I
>     expect the feature-creep to begin with including various other forms
>     of name identifiers, such as email or social-site-based names, and
>     then getting into the need for an IdP model, SSO/SAML/OpenID, OAuth,
>     etc.  Or we start debating how to distinguish legitimate financial
>     banks from blood banks and sperm banks; or how users receiving just
>     the string "Fidelity" disambiguate when they get calls from:
>     Fidelity Investments, Fidelity National Financial, Fidelity National
>     Information Services, USS Fidelity, Fidelity Records, Fidelity IL,
>     Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or
>     Fidelity Township NJ. (all legal, separate entities in the US)
>
>     I don't really know how to prevent such ratholes, but maybe we need
>     a separate mailing list for the name discussions (i.e. for a
>     research/design-team) to separate that stuff out and keep this one
>     focused on the charter's scope?
>
>     -hadriel
>
>
>
>

---

From: Cary FitzGerald <[email-masked]>
Date: Fri, 23 Aug 2013 15:16:48 -0700

In the end, as Hadriel points out, the question is scope.

What is it?
	Meta (and meta-meta) data:  an identity, an asserting authority (recognizing that the assertion that a session came from any particular PSTN number is imperfect) and a translation authority.
	In scope.

How do I get it?
	In band, out of band, whatever.
	In scope.

For the first two questions, the answers may be very similar or the same as mechanisms that this community has been working on for 10+ years.

How do my agents (UA, service providers) use it?
	A mechanism to query the reputation of the asserting and translating authorities (including an assessment of the policy regarding asserting that the number is, in fact, my "number" number, whatever that means)?
	In/out of scope (recognizing that now there is a meta-meta-meta data issue)?

Who are the authorities?
	Mechanisms to specify what does the name mean, who paid (whose interests are represented) to have it inserted and/or translated?
	Out of scope?
	Cullen's reticence to take a call from someone who hasn't asserted themselves to be someone he's talked to in the past?
	Out of scope.

How do I translate all that information into meaning?
	Something that Brian, Cullen, Hadriel, Mike can use?  (Also, my friend Howard S. Bradford-Carlson Banks, you've probably seen him around).
	Something my dad can use - he's a real problem because "knows" stuff about ANI.  As a good friend of mine quoted to me:  "It's not what you don't know that kills you.  It's what you do know that just ain't so."
	Out of scope.

The existing charter talks a lot about end user behaviors, which is sort of helpful as a benchmark, but is also hard to objectively assess.

Cary.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 24 Aug 2013 02:12:35 +0000

Just to clarify, as my original description obviously was lacking:

I see two models, the "by-value" (display name or similar call-info information) version, along the lines that Brian has been describing, and the "by-reference" lookup model.

For the latter, my rough notion is similar to whois - the (validated) phone number becomes a key into one or more databases. Unlike CNAM, it wouldn't be hard to have several, including ones operated by major carriers and third-party certifiers (e.g., a regulatory agency, such as a financial regulator, or professional licensing entity). Besides a query protocol that end systems can execute, you don't need much. Primarily, the local bar association needs to be able to ascertain that Attorney-at-Law Smith is entitled to use the phone number he claims in his profile.

For the by-value model, I see this as a useful generalization of the IKE and 4474bis concepts, namely that a call request can have multiple 

(objects signed, signature, binding)

headers. Thus, you could have

(calling number, signature using STIR key, Date/To/...)

as well as

(display name, signature using PK of verizon.com, Date/To/...)

This allows for the case that the carrier or a third party validates the calling entity business name. This simply says "this is the name inserted by the carrier, not the caller or some third party". Whether that is sufficient to be useful depends on the policy of the signer. This requires that the callee can verify that verizon.com is indeed the carrier of record for this number.

I don't think it's as useful to have the entity assigned the number use its STIR key to sign, as that simply indicates that nobody else has messed with the display information.

I don't expect users to evaluate this - much of the filtering and scoring will be done by third parties on behalf of the callee. If pinkcarrier.com signs any garbage, this will land them on the do-not-trust list fairly quickly and reputable businesses that prefer to not be tarred by that behavior may decide to go elsewhere.

We also seem to have no difficulty dealing with gray in spam filtering, as in the scores that SpamAssassin attaches to messages.

I don't see disagreement that verifiable names are not foolproof or can prevent all fraudulent activity. I'm happy if it raises the bar or roughly restores the level of trust that existed in the pre-VoIP days.

Henning

________________________________________
From: [email-masked] [[email-masked]] on behalf of Dwight, Timothy M (Tim) [[email-masked]]
Sent: Friday, August 23, 2013 3:38 PM
To: Hadriel Kaplan; Brian Rosen
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,      Early Homework)

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Friday, August 23, 2013 1:44 PM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework)

That's a good point.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 24 Aug 2013 02:25:35 +0000

To make this a bit more concrete, a few years ago Kumiko Ono and I worked on a related system that does a bit more.

See

http://www.cs.columbia.edu/~kumiko/IETF_doc/draft-ono-dispatch-attribute-validation-00.html

We didn't have validated numbers to rely on, so the trade-offs likely will lead to a different solution with STIR.

Henning

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 24 Aug 2013 00:12:44 -0400

I've thought about that first by-reference model before as well, but I'm pretty sure nothing needs to change in IKES/4474bis to achieve it someday.  Not 100% sure, but pretty sure.

For the second one, I'm also pretty sure nothing needs to change in IKES/4474bis, since you're talking about it as using a separate header/key/signature/etc.  Right?

I actually think there are additional, completely different, ways to achieve this.  But we can take that discussion off to a new list. :)

For the shades-of-gray scoring complexity, I don't think email is very analogous, in the sense that email has a lot of information to make spam determination with.  Phone call requests... not so much; and human/business name strings even less so.  Realistically it would boil down to whether you trust the signing carrier/identity-service or not, kinda similar to the old email DNSBLs.  [Btw, there were lawsuits over DNSBLs, but the lawsuits were eventually defeated]

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Aug 2013 14:48:11 +0000

I agree as long as we have sufficient flexibility and clarity on exactly what signing means (e.g., we may need to discuss string normalization rules, in case SBCs un-fold display names or change white spaces in display names).

For scoring, I suspect we need two different indicators, namely a description of how the originating carrier or other entity knows the name of the caller and a confidence level. If you look at identity verification today, performed by companies such as Experian, they provide such 0-100 scores. This is purely based on identity, not on any content. The similarity is simply that filtering entities have figured out ways to set thresholds on those numbers, based on experience and risk/nuisance tolerance.

For the indicator, I'm picturing indications such as "no verification" (this would be for cash prepay), "consumer billing relationship" (where the credit card name agrees with the display name) to "commercial billing relationship" (where the carrier is dealing with a known entity that it extends credit to and presumably has validated using typical commercial credit checks).

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Saturday, August 24, 2013 12:13 AM
To: Henning Schulzrinne
Cc: [email-masked] WG
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework)

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Mon, 26 Aug 2013 11:56:26 -0400

We have three players:
1. The origination device or service provider
2. The validation service
3. The termination device or service provider

The origination asserts a name
The validation service validates it and creates a score.  It protects it in
some way that makes the package (name and score) not modifiable and where
the identity of the validation service is preserved
The origination carries the package in the signaling

I believe that keeping the name separate from the number won't work.  The
same entity that asserts the number asserts the name.  So, I think that the
package is covered by the signature of the entity that asserts the name and
the number.  One way to do this is to have the score a parameter in the
header we're discussing for number, as well as a signature of the score,
name and number created by the validator.

What is needed is a way to extend the header to add parameters that are
covered by the signature of the number holder.
We could then use that to add the score and validator signature for the
name.

Brian

On Mon, Aug 26, 2013 at 10:48 AM, Henning Schulzrinne <
[email-masked]> wrote:

> I agree as long as we have sufficient flexibility and clarity on exactly
> what signing means (e.g., we may need to discuss string normalization
> rules, in case SBCs un-fold display names or change white spaces in display
> names).
>
> For scoring, I suspect we need two different indicators, namely a
> description of how the originating carrier or other entity knows the name
> of the caller and a confidence level. If you look at identity verification
> today, performed by companies such as Experian, they provide such 0-100
> scores. This is purely based on identity, not on any content. The
> similarity is simply that filtering entities have figured out ways to set
> thresholds on those numbers, based on experience and risk/nuisance
> tolerance.
>
> For the indicator, I'm picturing indications such as "no verification"
> (this would be for cash prepay), "consumer billing relationship" (where the
> credit card name agrees with the display name) to "commercial billing
> relationship" (where the carrier is dealing with a known entity that it
> extends credit to and presumably has validated using typical commercial
> credit checks).
>
> I've thought about that first by-reference model before as well, but I'm
> pretty sure nothing needs to change in IKES/4474bis to achieve it someday.
>  Not 100% sure, but pretty sure.
>
> For the second one, I'm also pretty sure nothing needs to change in
> IKES/4474bis, since you're talking about it as using a separate
> header/key/signature/etc.  Right?
>
> I actually think there are additional, completely different, ways to
> achieve this.  But we can take that discussion off to a new list. :)
>
> For the shades-of-gray scoring complexity, I don't think email is very
> analogous, in the sense that email has a lot of information to make spam
> determination with.  Phone call requests... not so much; and human/business
> name strings even less so.  Realistically it would boil down to whether you
> trust the signing carrier/identity-service or not, kinda similar to the old
> email DNSBLs.  [Btw, there were lawsuits over DNSBLs, but the lawsuits were
> eventually defeated]
>
> -hadriel
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Aug 2013 20:36:45 -0400

[We REALLY need to take this discussion off this list - it's a horse of a different color]

On Aug 26, 2013, at 11:56 AM, Brian Rosen <[email-masked]> wrote:

> The validation service validates it and creates a score.  It protects it in some way that makes the package (name and score) not modifiable and where the identity of the validation service is preserved

You mean like a certificate signed by the validation service "CA"?  :)

> The origination carries the package in the signaling 

That would be putting a certificate in the SIP message, which we've already said is a bridge too far.  If we're willing to do it for calling name, then we should be willing to do it for calling number.

> I believe that keeping the name separate from the number won't work.  The same entity that asserts the number asserts the name.  

If the same entity that asserts the number asserts the name, and the same verifier verifies them, then I don't think you need to carry the validation service's signed certificate in the SIP message.  Have the originator upload the signed calling name "package" into the same STIR database used for calling number public keys.  The verifier retrieves it on SIP receipt.  You still don't need the SIP message's STIR signature sign anything extra.

> So, I think that the package is covered by the signature of the entity that asserts the name and the number.  One way to do this is to have the score a parameter in the header we're discussing for number, as well as a signature of the score, name and number created by the validator.  

I don't see why we need to protect the name from modification.  All the verifier has to do is do a string match of the received calling name vs. the one it finds a "package" for in the STIR database for the number.  We know the SIP message came from the number because of STIR, ergo we know what possible name(s) it could assert due to the "package".

If a malicious party tries to change the name, it fails.  If a malicious party tries to re-use the STIR signed stuff in a new message with a different name, it fails.  You're not preventing anything by signing the name.  

If there are multiple possible names for a given number, singing it would prevent someone from being able to change it from one valid name to another.  And if the name was empty in the SIP message (like the caller wanted to withhold the name), then a malicious party could fill it in with the valid name of the caller.  But we've already agreed that we're not worried about MITM for STIR, so I don't know why we'd be worried about this particular attack vector.

> What is needed is a way to extend the header to add parameters that are covered by the signature of the number holder.
> We could then use that to add the score and validator signature for the name.

The only purpose/value to digitally signing something is to prove that you generated the something.  For example to prevent someone else from changing the thing you signed without breaking your signature, and for others to know your key signed it.  [Of course they don't actually know who "you" are, except by having something else (such as a cert) binding your public key to an identity of some kind (such as a phone number)]

-hadriel