Subject: Re: [stir] Reputation vs Display name (was Textual caller ID)

From: Alex Bobotek <[email-masked]>
Date: Mon, 26 Aug 2013 11:26:48 -0700

Tim's point about duplicate names and Hadrial's about similar names are important in anti-phishing and anti-spoofing contexts.  Identity (e.g., phone #), display name and reputation are different concepts.   The display name associated with a number may have some bearing on its reputation; however, display name  (e.g., "Example Bank" vs. "Examp1e Bank", duplicates and similar variations) is insufficient to permit humans to reliably discern reputation.  

I'm certainly not arguing against display names being certified by one or more parties, or there being reputable number<-->name mapping databases.  
I am arguing _for_ the optional inclusion of reputation information in a larger framework.  The end user can only to be protected from phishing and spoofing by the inclusion of reputation information.  

This reputation should be associated with an _identity_ and  may be based on 
* authorities' certifications of reputation (not just name)
* community-based reputation
* other means

The reputation-based models implemented in some browsers, commercial anti-virus solutions file reputation  and DKIM/DMARC in email all bear some relevance and are worth studying.  

IMHO, the model should allow for the inclusion of optional reputation information, allowing screening, and user agent display and reporting.

Regards,

Alex Bobotek
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Friday, August 23, 2013 7:13 PM
To: Dwight, Timothy M (Tim); Hadriel Kaplan; Brian Rosen
Cc: [email-masked]
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework)

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)

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)

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Aug 2013 21:14:23 +0000

I'm very confused by this whole thread. Do the folks advocating this extension of scope want to rerun the stir BoF in Vancouver? If not, please say how this fits the current draft charter.

The reason for my concern btw is less process than a serious worry that stir will fail if this is anywhere near the initial scope.

S

---

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

On Aug 26, 2013, at 5:14 PM, Stephen Farrell <[email-masked]> wrote:

> I'm very confused by this whole thread. Do the folks advocating this extension of scope want to rerun the stir BoF in Vancouver?

I don't think anyone has proposed that. (I hope?)

> If not, please say how this fits the current draft charter.

It doesn't.  Richard Barnes sent in a request today for a separate mailing list for the calling name stuff.  I don't know how long it takes to get one created though.

> The reason for my concern btw is less process than a serious worry that stir will fail if this is anywhere near the initial scope.

yup.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 27 Aug 2013 08:51:36 -0400

+1  however a "shaken" list for not charter issues would not be
unreasonable. It is a interesting thread and holds promise for future
implementations.

It is August after all. The charter is not yet approved. Conversations often
become long winded.

Ok question ... pretend you wanted a good primer "PKI for Teleco Dummies"
any suggestions?  Where would you start?  

Any good comparisons of various PKI implementations in the field?
Successes failures etc? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Monday, August 26, 2013 8:40 PM
To: Stephen Farrell
Cc: [email-masked] WG
Subject: Re: [stir] Reputation vs Display name (was Textual caller ID)

On Aug 26, 2013, at 5:14 PM, Stephen Farrell <[email-masked]>
wrote:

> I'm very confused by this whole thread. Do the folks advocating this
extension of scope want to rerun the stir BoF in Vancouver?

> If not, please say how this fits the current draft charter.

It doesn't.  Richard Barnes sent in a request today for a separate mailing
list for the calling name stuff.  I don't know how long it takes to get one
created though.

> The reason for my concern btw is less process than a serious worry that
stir will fail if this is anywhere near the initial scope.

yup.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 27 Aug 2013 09:04:38 -0400

Or more appropriately ... PKI for Telecom Regulators. ( no they are not
dummies)

Seriously I was chatting with Hadriel privately and at some point given the
scope of this effort a STIR FAQ document may be very very useful. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Shockey
Sent: Tuesday, August 27, 2013 8:52 AM
To: 'Hadriel Kaplan'; 'Stephen Farrell'
Cc: [email-masked]
Subject: Re: [stir] Reputation vs Display name (was Textual caller ID)

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

yup.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Aug 2013 09:14:50 -0400

I've written one - it's almost 30 pages.  It includes a short bit on what a PKI is, and its various flavors.
I'll send it to you to see if it answers your questions well enough, or if it needs more work.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 27 Aug 2013 17:53:32 +0000

+1  

STIR was getting derailed.

Mike

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

yup.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2013 14:21:02 -0400

<we should be getting a new list shortly>
Replying to this message that drifted the original thread.

I personally want to keep this effort out of research and firmly in things
we know how to do now.  That means, to me, that reputation is not useful,
because we don't have a notion of identity that we can work from, and we
don't have any metrics that would allow us to build reputation systems for
this application.

We DO know how to do reasonable, but not entirely accurate, validation of
names against numbers, especially if, as we can reasonably do, we get
additional information from the origination service provider to do the
validation.  We do that now, pretty successfully.  We can imagine extending
the kinds of things we do now in the direction Tim, Henning, and others
have suggested - primarily, the notion of having a taxonomy of callers
(like "bank") and labeling the caller with the taxonomy in a reasonably
accurate way.  Based on the kinds of databases that exist, doing validation
against an agreed upon taxonomy is not research.  I think agreeing on the
taxonomy is likely the hardest problem.

But the kind of reputation systems I'm aware of would not give us an
engineering basis to build equivalents for caller names, at least at
present.

Brian

On Mon, Aug 26, 2013 at 2:26 PM, Alex Bobotek <[email-masked]> wrote:

> Tim's point about duplicate names and Hadrial's about similar names are
> important in anti-phishing and anti-spoofing contexts.  Identity (e.g.,
> phone #), display name and reputation are different concepts.   The display
> name associated with a number may have some bearing on its reputation;
> however, display name  (e.g., "Example Bank" vs. "Examp1e Bank", duplicates
> and similar variations) is insufficient to permit humans to reliably
> discern reputation.
>
> I'm certainly not arguing against display names being certified by one or
> more parties, or there being reputable number<-->name mapping databases.
> I am arguing _for_ the optional inclusion of reputation information in a
> larger framework.  The end user can only to be protected from phishing and
> spoofing by the inclusion of reputation information.
>
> The reputation-based models implemented in some browsers, commercial
> anti-virus solutions file reputation  and DKIM/DMARC in email all bear some
> relevance and are worth studying.
>
> IMHO, the model should allow for the inclusion of optional reputation
> information, allowing screening, and user agent display and reporting.
>
> Regards,
>
> Alex Bobotek
> [email-masked]
>
> Henning Schulzrinne
> 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
>
> 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.comsigns 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]]
> 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
>
> > 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: Stephen Farrell <[email-masked]>
Date: Tue, 27 Aug 2013 18:40:57 +0000

On þri 27.ágú 2013 18:21, Brian Rosen wrote:
>
> We DO know how to do reasonable, but not entirely accurate, validation 
> of names against numbers, especially if, as we can reasonably do, we 
> get additional information from the origination service provider to do 
> the validation.  We do that now, pretty successfully.  We can imagine 
> extending the kinds of things we do now in the direction Tim, Henning, 
> and others have suggested - primarily, the notion of having a taxonomy 
> of callers (like "bank") and labeling the caller with the taxonomy in 
> a reasonably accurate way.  Based on the kinds of databases that 
> exist, doing validation against an agreed upon taxonomy is not research.
FWIW, I don't think we know how to do that in a PKI (or DKIM-like 
equivalent) that is being established to issue credentials just for 
phone numbers. I think I saw Steve Kent say the same thing earlier as 
well. Dealing with people's
names and businesses names like that just has a lot of complexity, or at 
least has had in any context in which I've encountered the problem. Just 
to throw one of many possible examples into the picture, the name 
Stiofán O'Fearghail would likely have to be accepted for me if an Irish 
regulator were deploying a STIR system that had to support people's 
names - are you saying you know how to handle all the i18n issues with 
naming that'd come up?

S.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2013 15:01:36 -0400

No one suggested we do that in a PKI/DKIM that is issuing credentials for
phone numbers.  I merely wish to be able to carry the validation
information as asserted by the entity signing the number.  The validator
service for the name is likely different from the number delegation
authority.

I repeat, often, that the mechanisms we use to do the name validation are
not perfect, and they are most often local (i.e. a given validation
database often only covers one, or a very small number of countries).  If
you attempted to use Stiofán O'Fearghail assuming you presently resided in
the U.S., you would get a very low score, unless you have regularly used
that name in a variety of commercial circumstances or public records.  Even
if your birth certificate used that version of your name, if you didn't
regularly use it, the database would score it low, even if you supplied
other information about yourself.  The same is very likely true of the
databases that cover Ireland, unless, again, that was how you represented
yourself commonly, especially in commercial transactions or public records,
but I am less familiar with them than the U.S. databases.

Each of these databases has different sources of data that it builds on,
and they have different methods of correcting bad data.  They are, however,
pretty darn reliable over all, even though they are not perfect.   I would
not suggest that we standardize how these databases work.  We only need to
recognize that they exist, that they supply a score, and that they work
better with more information suppled on a query, which leads me to try to
get validation done at the origination side, where more information is
typically available.  We don't have to standardize queries to these
databases, or anything other than the range of the score, where 0-100 is a
generally acceptable range.

Brian

On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell
<[email-masked]>wrote:

>> against an agreed upon taxonomy is not research.
>>
> equivalent) that is being established to issue credentials just for phone
> numbers. I think I saw Steve Kent say the same thing earlier as well.
> Dealing with people's
> least has had in any context in which I've encountered the problem. Just to
> throw one of many possible examples into the picture, the name Stiofán
> O'Fearghail would likely have to be accepted for me if an Irish regulator
> were deploying a STIR system that had to support people's names - are you
> saying you know how to handle all the i18n issues with naming that'd come
> up?
>
> S.
>
>