Re: [cnit] CNIT Charter bashing..

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

Henning,

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

tim

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

Today's CNAM display has three problems:

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

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


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

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


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

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

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


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

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

Tim


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

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

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

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

Brian
> On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) <[e-mail]> wrote:
>
> Who would assign the confidence value?  If it's assigned by the entity that operates the calling name database, why would it ever be less than the highest possible value?  If it's set by some other entity, on what basis do they determine the value they assign?  It seems like we're going to stumble over business issues.
>
> Tim
>
>
> -----Original Message-----
> From: cnit [mailto:[e-mail]] On Behalf Of Brian Rosen
> Sent: Friday, June 12, 2015 11:28 AM
> To: Richard Shockey
> Cc: [e-mail]; Henning Schulzrinne; [e-mail]; 
> Stephen Farrell
> Subject: Re: [cnit] CNIT Charter bashing..
>
> One possible extra bit is that we need to know WHO signed.  That could be easy (identity in a cert for the signature), but it's a requirement.
>
> I still want an optional confidence value, because the source is often not authoritative.
>
> If we're thinking we're using the existing display name, and coming up with a way to sign it, then, like stir, the termination side can decide what it wants to do if it gets a display name but no signature.  The sender has the option to provide the name or not, and provide the signature or not.
>
> We COULD consider a new header that would contain the name encrypted for a destination TN (To:).  That would afford privacy to the name to middle boxes that we would not have today with display name.  I would not be opposed to that.  This would work like the offline stir proposal, where the sender obtains the public key of the recipient and encrypts the name for the recipient.
>
> Brian
>
>> On Jun 12, 2015, at 8:49 AM, Richard Shockey <[e-mail]> wrote:
>>
>>
>> Henning is right. No one is forcing anything. Existing anonymous 
>> calling protections still apply.
>>
>>
>> Again my point is that is a great many cases Interconnected SIP 
>> between NA carriers are covered by other security mechanisms.
>>
>> Right now your Facetime session is totally in the clear. My concern 
>> is we end up going down the rat hole of trying to create perfect end 
>> to end security nothing will get done.
>>
>>
>>
>> On 6/12/15, 10:17 AM, "Stephen Farrell" <[e-mail]> wrote:
>>
>>>
>>>
>>> On 12/06/15 15:13, Henning Schulzrinne wrote:
>>>> In almost all cases of interest, the calling party *wants* to 
>>>> disclose accurate information to the called party, so the privacy 
>>>> issues don't seem to arise. They would only arise if there was 
>>>> forced disclosure; I don't think anybody is proposing that.
>>>
>>> Privacy issues could also arise if a middlebox could now see 
>>> sensitive information that it previously could not see. I think that 
>>> is independent of whether disclosure is desired by either of the 
>>> endpoints.
>>>
>>> S.
>>>
>>> _______________________________________________
>>> cnit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/cnit
>>
>>
>> _______________________________________________
>> cnit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cnit
>
> _______________________________________________
> cnit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cnit


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