Re: [cnit] CNIT Charter bashing..

Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> Fri, 12 June 2015 22:39 UTC

Return-Path: <Henning.Schulzrinne@fcc.gov>
X-Original-To: cnit@ietfa.amsl.com
Delivered-To: cnit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940031B2B90 for <cnit@ietfa.amsl.com>; Fri, 12 Jun 2015 15:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSIFiumTrdgB for <cnit@ietfa.amsl.com>; Fri, 12 Jun 2015 15:39:27 -0700 (PDT)
Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 123D91B2B66 for <cnit@ietf.org>; Fri, 12 Jun 2015 15:39:26 -0700 (PDT)
Message-ID: <E6A16181E5FD2F46B962315BB05962D07D3558F5@fcc.gov>
From: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
To: Brian Rosen <br@brianrosen.net>
Thread-Topic: [cnit] CNIT Charter bashing..
Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAAAqQYw==
Date: Fri, 12 Jun 2015 22:39:26 +0000
References: <D19F23AD.26CEA%richard@shockey.us> <E42CCDDA6722744CB241677169E8365603614617@MISOUT7MSGUSRDB.ITServices.sbc.com> <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <E6A16181E5FD2F46B962315BB05962D07D354C94@fcc.gov> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <D1A05A04.26E84%richard@shockey.us> <E6A16181E5FD2F46B962315BB05962D07D355543@fcc.gov> <557AE9E4.5030205@cs.tcd.ie> <D1A0761F.26EE1%richard@shockey.us> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com>, <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net>
In-Reply-To: <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cnit/O2YD4qP0kpSqc71vWKBfe5sTAUo>
Cc: "cnit@ietf.org" <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..
X-BeenThere: cnit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Calling Name Identity Trust discussion list <cnit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cnit>, <mailto:cnit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cnit/>
List-Post: <mailto:cnit@ietf.org>
List-Help: <mailto:cnit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cnit>, <mailto:cnit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 22:39:30 -0000

We have gone around that issue a few times, I think. Without trying to rehash the arguments, I think the value is completely meaningless to the recipient. The value is currently used within a closed environment - company A uses a validation service V and presumably gets a good sense of what "70" means and whether that value is sufficiently high to do whatever they need to do (extend credit, open an account, show tax return information). When company B receives this information, it is completely meaningless to that recipient, as the value will depend on what information the customer A provided, whether A used V, W or X for validation and when this information was validated. Does 70 mean that 70% of the customers with that type of information are indeed who they claim to be? Or just that the person answered 7 out of 10 questions correctly?

Thus, this information is meant to be interpreted within a particular context, and taking it out of this context renders it meaningless.

Thus, unless these issues can be addressed, we would be conveying information that pretends to be accurate, but is just noise. Brian, you repeat the same idea, but never address the issues that get raised again and again. This is not helpful.

We also now know from the IRS tax return debacle that knowledge-based authentication varies in quality. I'm sure whoever got access to the tax returns scored a 100 on whatever questions the web site asked...

________________________________________
From: Brian Rosen [br@brianrosen.net]
Sent: Friday, June 12, 2015 1:51 PM
To: Dwight, Timothy M (Tim)
Cc: Richard Shockey; philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org; 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) <timothy.dwight@verizon.com> 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:cnit-bounces@ietf.org] On Behalf Of Brian Rosen
> Sent: Friday, June 12, 2015 11:28 AM
> To: Richard Shockey
> Cc: philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org; 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 <richard@shockey.us> 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" <stephen.farrell@cs.tcd.ie> 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
>>> cnit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cnit
>>
>>
>> _______________________________________________
>> cnit mailing list
>> cnit@ietf.org
>> https://www.ietf.org/mailman/listinfo/cnit
>
> _______________________________________________
> cnit mailing list
> cnit@ietf.org
> https://www.ietf.org/mailman/listinfo/cnit