Re: [cnit] CNIT Charter bashing..

[Richard Shockey <[e-mail]>]

Henning the biggest issue is that any form of advanced CNAM display is not
currently applicable to the the mobile access devices. Which are now
finally over 50% of the NANP even if you consider BYOD in the enterprise.
Yea that is another use case.

Hence the issue with Apple. This is ultimately a problem with that will
have to be coordinated with US GSMA or GSMA generally.

Or IMHO with the the 8th floor on 12th st. It really is a jawboning use.
Tom needs to call Tim Cook or Larry Page and make the ask.

I do reject Brians pretense here. Given the IETF context perfection is
actually the enemy of deployment.

I want a charter that is simple and clear.  Header and object. Period.  If
that is impossible then Š..

Its time the AD¹s decide.


‹ 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN [phone]





On 6/12/15, 6:28 PM, "Henning Schulzrinne" <[e-mail]>
wrote:

>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.
>
>(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.
>
>(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.
>
>________________________________________
>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
>