Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

["Gorman, Pierce A [NTK]" <[e-mail]>]

The issues we keep circling are trust and value.

For practical reasons, carriers are going to continue to want to use CNAM clearinghouse information providers, and consumers are going to continue to want better information.  If the consumes are like me, they're going to be willing to pay a little extra to get better information, or be unwilling to pay but willing to just deal with liars calling.  Nobody is forced to answer or to believe anything they're told if they do answer.

Mechanisms are already in place to support real-time per-call per-subscriber 3rd party telecommunications services.  If KPMG or Prudential started offering information security services for CNAM, I'd pay for it.

IMHO, the focus of STIR and CNIT WGs should be mechanisms which 1) validate that a calling number is authentic (not trustworthy), and 2) provide a carrier or CNAM provider a key for retrieving (potentially untrustworthy)  information that has been associated with that calling number.

Ensuring the trustworthiness of the calling number or the information associated with the calling number should not be the domain of the IETF.

If trustworthiness of information is VALUABLE (and we've described multiple examples of this being so), then the marketplace can determine how the value is to be extracted and applied.

Pierce

-----Original Message-----
From: Michael Hammer [mailto:[e-mail]]
Sent: November 07, 2013 11:21 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]; Gorman, Pierce A [NTK]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

Agree, the user may trust the carrier or someone like FTC or FCC.

But, if it goes beyond a small handful, forget it.



Bottom line, the average user needs to know that someone has actually

gone to the business site and knocked on the door, met the people,

and seen that it is a real business.

Not, just some fly-by-night operation that logged into some website.



Mike





From: Henning Schulzrinne [mailto:[e-mail]]
Sent: Thursday, November 07, 2013 12:15 PM
To: Michael Hammer; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt



The user shouldn't and wouldn't - they would trust a third party (often, their carrier, I suspect) to figure out who can attest to the bankiness of a bank. This is not new - there are a number of existing outfits that do this for web sites. (Example: Avast has a bar graph that shows trustworthiness.)





From: Michael Hammer [mailto:[e-mail]]
Sent: Thursday, November 07, 2013 12:10 PM
To: [e-mail]; Henning Schulzrinne
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt



So, how does the average user know who is an authority?

(Note, we are not designing for IETF geniuses here.)



Is some well-known central authority going to certify all of these?

Are each of these going to cross-certify all the others? (federated model)



We need to always answer that fundamental user question:

Why should I TRUST this information?



Mike





From: Brian Rosen [mailto:[e-mail]]
Sent: Thursday, November 07, 2013 12:03 PM
To: Henning Schulzrinne
Cc: Michael Hammer; [e-mail]; Richard Shockey; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt



Right.  I believe we can do this pretty easily.  We probably could have a
100 categories that would have similar authorities, and there are classifications maintained by folks like Dun Bradstreet that can go even farther.



What I think would be substantially harder is to validate an entire V/X/J card.  How is a validator to know your nickname is Fluffy?  Name, phone number and, if a business, a classification, yes, we can do that.  Content of a business card - very hard.



Brian





On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne <[e-mail]> wrote:



Yes, that's a problem, but as long as the number of categories is small, you can build UIs that only render information that's appropriate to the declaration. For practical reasons, I think the number of useful categories is likely going to be fairly limited:

-          Financial institution (FDIC and a few others)

-          Health care (each health care facility has a gov't number)

-          Charity (501c3, state registered)

-          Contractor (state-licensed)

-          Public safety organization (police, fire)

-          Lawyer (bar association)

-          Local, state and federal government (.gov in the US)



I suspect that list encompasses a large fraction of the fraudulent
(impersonation) calls. For all of the above, at least within a country, it's pretty clear who can attest to the membership. Yes, this requires some UI work or some server logic, but these categories and the organizations don't change all that often - in most cases, the certifying entities have probably been the same for the past 50+ years. I'm not as worried about figuring out whether the beautician, mortician or florist is licensed and properly identified, although I'm sure we can all come up with potential fraud stories.



From: Michael Hammer [mailto:[e-mail]]
Sent: Thursday, November 07, 2013 10:28 AM
To: Henning Schulzrinne; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt



So, would you trust a certificate from the City of Reston, Virginia police department?



(Hint:  you can find Reston on a map, but there is no City of Reston.

  The only police are Fairfax County.)



My concern is that one you dilute or disperse authority, it becomes a free-for-all again, and anybody's guess.



Mike





From:  <mailto:[e-mail]> [e-mail] [ <mailto:[e-mail]> mailto:[e-mail]] On Behalf Of Henning Schulzrinne
Sent: Thursday, November 07, 2013 10:00 AM
To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey
Cc:  <mailto:[e-mail]> [e-mail] List; Fernando Mousinho (fmousinh);  <mailto:[e-mail]> [e-mail]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt



As a thought experiment, Kumiko Ono and I had published a draft



 <http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00>
http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00



to allow third parties to validate property information. If the validating party (e.g., a bank regulator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist's office or, more lowly, to the health departments rating in a restaurant window, and it can be tied to a phone number, this shouldn't be too hard.



It's a bit harder if the certifying authority (regulator, Realtor board, local bar association, .) is not involved.



Henning



From:  <mailto:[e-mail]> [e-mail] <mailto:[mailto:[e-mail]]> [mailto:[e-mail]] On Behalf Of Gorman, Pierce A [NTK]
Sent: Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard Shockey
Cc:  <mailto:[e-mail]> [e-mail] List;  <mailto:[e-mail]> [e-mail]; Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt



I'll admit I am not familiar with v/x/jcard encoding differences or the implications of their use so I'll encourage educating me if it isn't too onerous.



I'm not sure what is the concern with a 3rd party providing "validation"
though.  There are numerous examples of 3rd parties providing validation of information including NASDAQ, NYSE, Barron's, Moody's, and the federal reserve banking system to name a few.



Pierce



From: Brian Rosen [ <mailto:[e-mail]> mailto:[e-mail]]
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; <mailto:[e-mail]> [e-mail] List;  <mailto:[e-mail]> [e-mail]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt



I think this would be a heavy lift.



If the responsible entity was a carrier, then it would have to validate the data, which it has very little basis to validate.  It could get a 3rd party to do the validation, but then it's putting its reputation on the back of some hired hand validator.



If the responsibility is the end user/device, then the signature has no value.



I do not argue that Call-Info is suitable,  it is.



I do question JCARD vs xCard, but that's an encoding detail.  All of SIP Is XML described by schema, not json.



Brian



On Nov 6, 2013, at 1:10 PM, Richard Shockey < <mailto:[e-mail]> [e-mail]> wrote:



URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity.  The carrier could provision this for their mobile or hosted customers.  Enterprises could do this themselves.  This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise "directory" and could facilitate end to end PPX to PBX communications especially in point to point video communications.



There are certainly privacy and security issues to be addressed.  The Push vs Pull model.  This really would be PII in the clear but then its done voluntarily.



There would have to be some work around restructuring the Header and adding some parameters but it's underutilized right now and this Use Case is a perfectly appropriate use.



 <https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06>
https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06



Obviously it would need to be signed but we don't need to worry about that ..yet.



________________________________

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