Re: [cnit] Who says I am me? I say it is me. I have no reason to trust you.

["Dwight, Timothy M (Tim)" <[e-mail]>]

Henning,

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

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

Tim


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

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

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

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

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

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

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

I fully agree with Henning here for two reasons.

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

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

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

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


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

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

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


_______________________________________________
cnit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cnit