From md3135@att.com Sun Sep 1 03:11:41 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365F321F9C20 for ; Sun, 1 Sep 2013 03:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12gSUR+pK0gp for ; Sun, 1 Sep 2013 03:11:36 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id B8D0221F9C13 for ; Sun, 1 Sep 2013 03:11:35 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 7d213225.2aaac297b940.5073961.00-565.13853785.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 01 Sep 2013 10:11:35 +0000 (UTC) X-MXL-Hash: 522312d773418b39-68f995b3df499e06ba0630bcd57473a7f0818de5 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 1d213225.0.5073912.00-102.13853652.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 01 Sep 2013 10:11:35 +0000 (UTC) X-MXL-Hash: 522312d73ae36e7d-827f077e36c7dd19b86386b98e8988a5302d75d8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r81ABTi1011078; Sun, 1 Sep 2013 06:11:29 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r81AB6Uw010961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Sep 2013 06:11:18 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 1 Sep 2013 10:10:52 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0123.003; Sun, 1 Sep 2013 06:10:52 -0400 From: "DOLLY, MARTIN C" To: "" Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: AQHOpoE/D2W7OYUa20eMtX086Z6iwJmwqhBe Date: Sun, 1 Sep 2013 10:10:51 +0000 Message-ID: <5EC50FD3-FD06-499A-BD01-9BC3FFFA5025@att.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> <521D53D9.2080008@alum.mit.edu> <15603CA4-534A-4CCB-9EC4-9EFFD17B8B47@brianrosen.net> <4B1956260CD29F4A9622F00322FE053193812973E1@BOBO1A.bobotek.net> <5CD91A23-CB33-47B6-9173-A8C5B62F7E40@oracle.com> <7EB0D650-FFF9-459B-8D14-CBD09871D44B@brianrosen.net> <52207A27.5010105@bbn.com> <0E552CE9-DE70-4B45-B230-EC9E68DDCDDE@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA3012B1526AD@FHDP! 1LUMXC7V31.us.one.verizon.com> <9D3DF6A2-F2F0-4766-B9B3-EBCBAB3C4299@oracle.com> <5220D5DB.8050804@dcrocker.net > <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.n! et>,<52224580.6030901@dcrocker.net> In-Reply-To: <52224580.6030901@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=E6l6U9hl c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=dXS0THe0lJ8A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=Ve0RsmuVQbcA:10 a=b8OvNEjo] X-AnalysisOut: [AAAA:8 a=k7Ga1wGzAAAA:8 a=48vgC7mUAAAA:8 a=gUK7imMbsrtrixP] X-AnalysisOut: [iCDgA:9 a=CjuIK1q_8ugA:10 a=qM39cor4HRgA:10 a=ClmATp4dOM8A] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=E1Snkw02GREA:10 a=lZB815dzVvQA:10] Cc: "cnit@ietf.org" , Stephen Kent , Henning Schulzrinne , "Dwight, Timothy M \(Tim\)" , Brian Rosen Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 10:11:41 -0000 Brian Your DB? With our data.... Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards =20 AT&T Labs - Network Technology +1-609-903-3360 md3135@att.com On Aug 31, 2013, at 3:36 PM, "Dave Crocker" wrote: > On 8/30/2013 10:40 AM, Brian Rosen wrote: >> Okay. We support dozens of customers who had serious fraud abuse >> until they started using our database to evaluate callers to their >> call center. >=20 > OK. Good starting point. Call centers represent specialized user organi= zations, with operators have some distinct skills and training, but a usefu= l reference. If the intended scope of the current work is... everyone in t= he world... then there are some issues in generalizing the experience from = a few dozen skilled user organizations to billions of individual users. Bu= t, again, a good starting point. >=20 >=20 >> Typically, they query with 3-6 fields. They get a >> score back. They decide how to handle the caller based on the score. >=20 > I assume that the call center operators have established procedures, rath= er than creating an action based personal whim of the moment. Again, this w= ould distinguish them from typical, mass-market end users. >=20 >=20 >> The part of this that I can't cite a specific example for is what >> some clever UI developer will come up with to use the data. >=20 > Unfortunately that part of the equation matters. Not necessarily the fin= e-grained detail, but the basic expectations of how information will get us= ed and by whom and whether it is pre-determined or decided in real-time. >=20 > That's why I am trying to distinguish between an architectural component = that implements policies -- the same as the filtering engine in email anti-= abuse systems today -- versus assumptions that end-users will be making rea= l-time decisions, largely based on raw information. >=20 > In fact, the essential difference is between having a software policy eng= ine with built-in rulesets, versus a 'wet' real-time policy formulation eng= ine. >=20 >=20 > > What I >> know is, it's useful, and we'll figure out a way. >=20 > Then you know more than I do, in spite of my background in usability desi= gn and the considerable industry experience in this space, which frankly en= courages caution in this realm. >=20 >=20 >> It might have >> binned responses. It might change the response if this is the first >> call from the identity. It might supply a thumbs up/down selection >> that is used for other callers. It might supply a Travelocity style >> rating. >=20 > So it turns out that what you've described is considerably more than clev= er UI design. >=20 > You've describe the effects of a policy engine that does its own analysis= and handling decisions. And indeed, that's exactly the distinction I'm su= ggesting for this work. With luck, that means we're disagreeing on some te= rminology, rather than some architecture. >=20 > However, this is not a small point. It is a key architectural component = and designing for that function, rather than designing for end-users, per s= e, is a fundamental difference. >=20 >=20 >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From Henning.Schulzrinne@fcc.gov Sun Sep 1 13:12:13 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D8611E811E for ; Sun, 1 Sep 2013 13:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEcwpacwSGcP for ; Sun, 1 Sep 2013 13:12:09 -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 26A9611E8176 for ; Sun, 1 Sep 2013 13:12:08 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Stephen Farrell , "cnit@ietf.org" Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxV Date: Sun, 1 Sep 2013 20:12:06 +0000 References: <52225DF8.4000000@cs.tcd.ie> In-Reply-To: <52225DF8.4000000@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 20:12:14 -0000 My short version is that we have two stages:=0A= =0A= (1) Restore (at least) textual caller ID, i.e., caller name carried in the = SIP From header, to the level of trustworthiness it generally had in the pr= e-VoIP days. Since we cannot eliminate untrustworthy participants in the sy= stem, we need to=0A= (a) prevent on-path alteration=0A= (b) indicate provenance of the information (e.g., was this inserted by the = caller, the caller's carrier or by the receiving carrier, CNAM-style)=0A= (c) possibly provide indications that allow the recipient to judge the trus= tworthiness of the information, such as whether the information was provide= d by the caller himself and whether the data was verified in some way (e.g.= , by billing record or a third-party business database).=0A= =0A= (2) Provide additional information, such as name and address of organizatio= n or any licenses or registrations (e.g., licensed bank, health care provid= er), to allow call recipients to filter or evaluate calls, aided by third p= arties.=0A= =0A= In both cases, the goal is to reduce the opportunities for impersonation-ba= sed fraud. (I'm intentionally saying "reduce", not "eliminate".) The goal o= f this effort is *not* to reduce robocalls, although some aspects of approa= ch (2) may help there.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: cnit-bounces@ietf.org [cnit-bounces@ietf.org] on behalf of Stephen Fa= rrell [stephen.farrell@cs.tcd.ie]=0A= Sent: Saturday, August 31, 2013 5:19 PM=0A= To: cnit@ietf.org=0A= Subject: [cnit] what's the actual problem here?=0A= =0A= So having caught up on this list what I've seen is Brian proposing=0A= solutions, Henning discussing aspects of those, and various people=0A= apparently being puzzled or doubting some of the solutions being=0A= offered.=0A= =0A= I'm in the puzzled camp:-)=0A= =0A= Can someone please state the problem that this list is aiming to=0A= discuss, without referring to potential solutions?=0A= =0A= That'd help me at least get a handle on whether this is worthwhile=0A= or not, which is anything but clear for me right now.=0A= =0A= Thanks,=0A= S.=0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= From stephen.farrell@cs.tcd.ie Sun Sep 1 13:21:18 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE59E21F9D3A for ; Sun, 1 Sep 2013 13:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBg5Am51YvTS for ; Sun, 1 Sep 2013 13:21:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F2DA521F9E5C for ; Sun, 1 Sep 2013 13:21:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6DE6FBED6; Sun, 1 Sep 2013 21:21:06 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcxWjtNbH7Ka; Sun, 1 Sep 2013 21:21:05 +0100 (IST) Received: from [10.87.48.15] (unknown [86.41.60.246]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3B5C8BE8B; Sun, 1 Sep 2013 21:21:05 +0100 (IST) Message-ID: <5223A1A6.50507@cs.tcd.ie> Date: Sun, 01 Sep 2013 21:20:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: <52225DF8.4000000@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "cnit@ietf.org" Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 20:21:19 -0000 So you're saying the problem is: "people/systems are faking textual caller ID" is that right? I'm not familiar with textual caller ID as a (pre- or post-)VoIP service. I assume you mean that a call from me might say something resembling "stephen farrell" though, is that right? Do you have any pointers as to where/when this has been deployed? I don't think I've seen it being used with the strings coming from a telco. but maybe its more a US thing or something? S. On 09/01/2013 09:12 PM, Henning Schulzrinne wrote: > My short version is that we have two stages: > > (1) Restore (at least) textual caller ID, i.e., caller name carried in the SIP From header, to the level of trustworthiness it generally had in the pre-VoIP days. Since we cannot eliminate untrustworthy participants in the system, we need to > (a) prevent on-path alteration > (b) indicate provenance of the information (e.g., was this inserted by the caller, the caller's carrier or by the receiving carrier, CNAM-style) > (c) possibly provide indications that allow the recipient to judge the trustworthiness of the information, such as whether the information was provided by the caller himself and whether the data was verified in some way (e.g., by billing record or a third-party business database). > > (2) Provide additional information, such as name and address of organization or any licenses or registrations (e.g., licensed bank, health care provider), to allow call recipients to filter or evaluate calls, aided by third parties. > > In both cases, the goal is to reduce the opportunities for impersonation-based fraud. (I'm intentionally saying "reduce", not "eliminate".) The goal of this effort is *not* to reduce robocalls, although some aspects of approach (2) may help there. > > Henning > > ________________________________________ > From: cnit-bounces@ietf.org [cnit-bounces@ietf.org] on behalf of Stephen Farrell [stephen.farrell@cs.tcd.ie] > Sent: Saturday, August 31, 2013 5:19 PM > To: cnit@ietf.org > Subject: [cnit] what's the actual problem here? > > So having caught up on this list what I've seen is Brian proposing > solutions, Henning discussing aspects of those, and various people > apparently being puzzled or doubting some of the solutions being > offered. > > I'm in the puzzled camp:-) > > Can someone please state the problem that this list is aiming to > discuss, without referring to potential solutions? > > That'd help me at least get a handle on whether this is worthwhile > or not, which is anything but clear for me right now. > > Thanks, > 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 > > From Henning.Schulzrinne@fcc.gov Sun Sep 1 13:31:37 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E0C21E80CB for ; Sun, 1 Sep 2013 13:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6sPCnnUf8PU for ; Sun, 1 Sep 2013 13:31:33 -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 5DA8A11E817B for ; Sun, 1 Sep 2013 13:31:28 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Stephen Farrell Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgABJAgD//75U4g== Date: Sun, 1 Sep 2013 20:31:26 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <5223A1A6.50507@cs.tcd.ie> In-Reply-To: <5223A1A6.50507@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 20:31:37 -0000 See http://en.wikipedia.org/wiki/Caller_ID=0A= =0A= This has existed for landline phones since the early 1990s.=0A= =0A= For cell phones, generally only the phone number is delivered, although som= e carriers are now offering name delivery, for a fee.=0A= =0A= Yes, it's generally the billing name that's delivered, which could be "S Fa= rrell" or "Joe's Pizza". In some cases, only the rough geographic location = ("Maine", "International") is shown, presumably based on country or area co= de.=0A= =0A= ________________________________________=0A= From: Stephen Farrell [stephen.farrell@cs.tcd.ie]=0A= Sent: Sunday, September 01, 2013 4:20 PM=0A= To: Henning Schulzrinne=0A= Cc: cnit@ietf.org=0A= Subject: Re: [cnit] what's the actual problem here?=0A= =0A= So you're saying the problem is:=0A= =0A= "people/systems are faking textual caller ID"=0A= =0A= is that right?=0A= =0A= I'm not familiar with textual caller ID as a (pre- or post-)VoIP=0A= service. I assume you mean that a call from me might say something=0A= resembling "stephen farrell" though, is that right? Do you have=0A= any pointers as to where/when this has been deployed? I don't think=0A= I've seen it being used with the strings coming from a telco. but=0A= maybe its more a US thing or something?=0A= =0A= S.=0A= =0A= On 09/01/2013 09:12 PM, Henning Schulzrinne wrote:=0A= > My short version is that we have two stages:=0A= >=0A= > (1) Restore (at least) textual caller ID, i.e., caller name carried in th= e SIP From header, to the level of trustworthiness it generally had in the = pre-VoIP days. Since we cannot eliminate untrustworthy participants in the = system, we need to=0A= > (a) prevent on-path alteration=0A= > (b) indicate provenance of the information (e.g., was this inserted by th= e caller, the caller's carrier or by the receiving carrier, CNAM-style)=0A= > (c) possibly provide indications that allow the recipient to judge the tr= ustworthiness of the information, such as whether the information was provi= ded by the caller himself and whether the data was verified in some way (e.= g., by billing record or a third-party business database).=0A= >=0A= > (2) Provide additional information, such as name and address of organizat= ion or any licenses or registrations (e.g., licensed bank, health care prov= ider), to allow call recipients to filter or evaluate calls, aided by third= parties.=0A= >=0A= > In both cases, the goal is to reduce the opportunities for impersonation-= based fraud. (I'm intentionally saying "reduce", not "eliminate".) The goal= of this effort is *not* to reduce robocalls, although some aspects of appr= oach (2) may help there.=0A= >=0A= > Henning=0A= >=0A= > ________________________________________=0A= > From: cnit-bounces@ietf.org [cnit-bounces@ietf.org] on behalf of Stephen = Farrell [stephen.farrell@cs.tcd.ie]=0A= > Sent: Saturday, August 31, 2013 5:19 PM=0A= > To: cnit@ietf.org=0A= > Subject: [cnit] what's the actual problem here?=0A= >=0A= > So having caught up on this list what I've seen is Brian proposing=0A= > solutions, Henning discussing aspects of those, and various people=0A= > apparently being puzzled or doubting some of the solutions being=0A= > offered.=0A= >=0A= > I'm in the puzzled camp:-)=0A= >=0A= > Can someone please state the problem that this list is aiming to=0A= > discuss, without referring to potential solutions?=0A= >=0A= > That'd help me at least get a handle on whether this is worthwhile=0A= > or not, which is anything but clear for me right now.=0A= >=0A= > Thanks,=0A= > S.=0A= > _______________________________________________=0A= > cnit mailing list=0A= > cnit@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/cnit=0A= > _______________________________________________=0A= > cnit mailing list=0A= > cnit@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/cnit=0A= >=0A= >=0A= From stephen.farrell@cs.tcd.ie Sun Sep 1 13:40:17 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0490921E80D8 for ; Sun, 1 Sep 2013 13:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfs3KcOTzuer for ; Sun, 1 Sep 2013 13:40:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DE20111E817B for ; Sun, 1 Sep 2013 13:40:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0A900BE8F; Sun, 1 Sep 2013 21:40:09 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT6SgmNjDvcE; Sun, 1 Sep 2013 21:40:07 +0100 (IST) Received: from [10.87.48.15] (unknown [86.41.60.246]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 97134BE8B; Sun, 1 Sep 2013 21:40:07 +0100 (IST) Message-ID: <5223A627.8080704@cs.tcd.ie> Date: Sun, 01 Sep 2013 21:40:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: <52225DF8.4000000@cs.tcd.ie> , <5223A1A6.50507@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "cnit@ietf.org" Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 20:40:17 -0000 On 09/01/2013 09:31 PM, Henning Schulzrinne wrote: > See http://en.wikipedia.org/wiki/Caller_ID > > This has existed for landline phones since the early 1990s. Yes, I am familiar with seeing the caller's phone number presented, just not with names. > For cell phones, generally only the phone number is delivered, > although some carriers are now offering name delivery, for a fee. That's the bit I've not seen. The wiki page says that the names are mostly added by the recipient's telco, when a recipient pays for that service. (I'd imagine some EU data protection folks might have an interest in that btw - any idea if they've looked at it?) Also, does "now offering" imply this is a new-ish thing? If so, then I'm confused by your text saying a goal is to restore a level of confidence that's been damaged. > Yes, it's generally the billing name that's delivered, which could be > "S Farrell" or "Joe's Pizza". In some cases, only the rough > geographic location ("Maine", "International") is shown, presumably > based on country or area code. Ok, S. > > ________________________________________ From: Stephen Farrell > [stephen.farrell@cs.tcd.ie] Sent: Sunday, September 01, 2013 4:20 PM > To: Henning Schulzrinne Cc: cnit@ietf.org Subject: Re: [cnit] what's > the actual problem here? > > So you're saying the problem is: > > "people/systems are faking textual caller ID" > > is that right? > > I'm not familiar with textual caller ID as a (pre- or post-)VoIP > service. I assume you mean that a call from me might say something > resembling "stephen farrell" though, is that right? Do you have any > pointers as to where/when this has been deployed? I don't think I've > seen it being used with the strings coming from a telco. but maybe > its more a US thing or something? > > S. > > On 09/01/2013 09:12 PM, Henning Schulzrinne wrote: >> My short version is that we have two stages: >> >> (1) Restore (at least) textual caller ID, i.e., caller name carried >> in the SIP From header, to the level of trustworthiness it >> generally had in the pre-VoIP days. Since we cannot eliminate >> untrustworthy participants in the system, we need to (a) prevent >> on-path alteration (b) indicate provenance of the information >> (e.g., was this inserted by the caller, the caller's carrier or by >> the receiving carrier, CNAM-style) (c) possibly provide indications >> that allow the recipient to judge the trustworthiness of the >> information, such as whether the information was provided by the >> caller himself and whether the data was verified in some way (e.g., >> by billing record or a third-party business database). >> >> (2) Provide additional information, such as name and address of >> organization or any licenses or registrations (e.g., licensed bank, >> health care provider), to allow call recipients to filter or >> evaluate calls, aided by third parties. >> >> In both cases, the goal is to reduce the opportunities for >> impersonation-based fraud. (I'm intentionally saying "reduce", not >> "eliminate".) The goal of this effort is *not* to reduce robocalls, >> although some aspects of approach (2) may help there. >> >> Henning >> >> ________________________________________ From: >> cnit-bounces@ietf.org [cnit-bounces@ietf.org] on behalf of Stephen >> Farrell [stephen.farrell@cs.tcd.ie] Sent: Saturday, August 31, 2013 >> 5:19 PM To: cnit@ietf.org Subject: [cnit] what's the actual problem >> here? >> >> So having caught up on this list what I've seen is Brian proposing >> solutions, Henning discussing aspects of those, and various people >> apparently being puzzled or doubting some of the solutions being >> offered. >> >> I'm in the puzzled camp:-) >> >> Can someone please state the problem that this list is aiming to >> discuss, without referring to potential solutions? >> >> That'd help me at least get a handle on whether this is worthwhile >> or not, which is anything but clear for me right now. >> >> Thanks, 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 > > From dhc@dcrocker.net Sun Sep 1 13:52:04 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD6621E80EE for ; Sun, 1 Sep 2013 13:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQSf2jSrU-BQ for ; Sun, 1 Sep 2013 13:52:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4685821E80E9 for ; Sun, 1 Sep 2013 13:51:50 -0700 (PDT) Received: from [192.168.1.116] (cpe-76-93-128-131.san.res.rr.com [76.93.128.131]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r81KpVgQ002225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 1 Sep 2013 13:51:35 -0700 Message-ID: <5223A8CA.90402@dcrocker.net> Date: Sun, 01 Sep 2013 13:51:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: <52225DF8.4000000@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 01 Sep 2013 13:51:35 -0700 (PDT) Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 20:52:05 -0000 On 9/1/2013 1:12 PM, Henning Schulzrinne wrote: > (1) Restore (at least) textual caller ID, i.e., caller name carried in the SIP From header, to the level of trustworthiness it generally had in the pre-VoIP days Is there a description of what that original level of trustworthiness was? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From md3135@att.com Sun Sep 1 14:31:13 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E5D21F9FB3 for ; Sun, 1 Sep 2013 14:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAqNu7eVvG+R for ; Sun, 1 Sep 2013 14:31:07 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4375821F8263 for ; Sun, 1 Sep 2013 14:31:07 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b12b3225.5bb09940.6252055.00-566.17212982.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 01 Sep 2013 21:31:07 +0000 (UTC) X-MXL-Hash: 5223b21b0beaacfb-8802c40bcd085ead9391d9505608da7619852fb6 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 312b3225.0.6252027.00-399.17212898.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 01 Sep 2013 21:31:06 +0000 (UTC) X-MXL-Hash: 5223b21a4da339c4-b4d149997ee4354eaa0b08d531ac0d364647f230 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r81LUwcY014953; Sun, 1 Sep 2013 17:30:59 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r81LUi9s014814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Sep 2013 17:30:46 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 1 Sep 2013 21:30:34 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0123.003; Sun, 1 Sep 2013 17:30:34 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOpo/kSqURJiscwkaRCGckZH0pJpmxlP0A///S3gI= Date: Sun, 1 Sep 2013 21:30:33 +0000 Message-ID: <2B6E7532-DA99-47B3-A76F-F662D9E038A1@att.com> References: <52225DF8.4000000@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=Ru1y2laK c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=vc5lCoSdESQA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=WRdS7oYUjucA:10 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=nLR0eJmsM2IfvTcaoMYA:9 a=CjuIK1q_8ugA:10 a=qM39co] X-AnalysisOut: [r4HRgA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:10 a=UnaT4kxof-] X-AnalysisOut: [9zrihp:21 a=KMcU6rJ3zNr8xWpa:21] Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 21:31:13 -0000 Henning in all due respect nothing dictates the behavior you say ?=20 So magic and fairy dust makes it so?=20 Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards =20 AT&T Labs - Network Technology +1-609-903-3360 md3135@att.com On Sep 1, 2013, at 4:12 PM, "Henning Schulzrinne" wrote: > My short version is that we have two stages: >=20 > (1) Restore (at least) textual caller ID, i.e., caller name carried in th= e SIP From header, to the level of trustworthiness it generally had in the = pre-VoIP days. Since we cannot eliminate untrustworthy participants in the = system, we need to > (a) prevent on-path alteration > (b) indicate provenance of the information (e.g., was this inserted by th= e caller, the caller's carrier or by the receiving carrier, CNAM-style) > (c) possibly provide indications that allow the recipient to judge the tr= ustworthiness of the information, such as whether the information was provi= ded by the caller himself and whether the data was verified in some way (e.= g., by billing record or a third-party business database). >=20 > (2) Provide additional information, such as name and address of organizat= ion or any licenses or registrations (e.g., licensed bank, health care prov= ider), to allow call recipients to filter or evaluate calls, aided by third= parties. >=20 > In both cases, the goal is to reduce the opportunities for impersonation-= based fraud. (I'm intentionally saying "reduce", not "eliminate".) The goal= of this effort is *not* to reduce robocalls, although some aspects of appr= oach (2) may help there. >=20 > Henning >=20 > ________________________________________ > From: cnit-bounces@ietf.org [cnit-bounces@ietf.org] on behalf of Stephen = Farrell [stephen.farrell@cs.tcd.ie] > Sent: Saturday, August 31, 2013 5:19 PM > To: cnit@ietf.org > Subject: [cnit] what's the actual problem here? >=20 > So having caught up on this list what I've seen is Brian proposing > solutions, Henning discussing aspects of those, and various people > apparently being puzzled or doubting some of the solutions being > offered. >=20 > I'm in the puzzled camp:-) >=20 > Can someone please state the problem that this list is aiming to > discuss, without referring to potential solutions? >=20 > That'd help me at least get a handle on whether this is worthwhile > or not, which is anything but clear for me right now. >=20 > Thanks, > 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 From hadriel.kaplan@oracle.com Mon Sep 2 08:52:00 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D581021E8064 for ; Mon, 2 Sep 2013 08:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxfKeNH32H6t for ; Mon, 2 Sep 2013 08:51:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id BFCD421F89FF for ; Mon, 2 Sep 2013 08:51:45 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r82FpcMB015256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Sep 2013 15:51:40 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r82FpbXB027641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Sep 2013 15:51:37 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r82Fpa7D023725; Mon, 2 Sep 2013 15:51:37 GMT Received: from [192.168.2.6] (/69.131.62.50) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Sep 2013 08:51:36 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 2 Sep 2013 11:51:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> References: <52225DF8.4000000@cs.tcd.ie> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 15:52:01 -0000 On Sep 1, 2013, at 4:12 PM, Henning Schulzrinne = wrote: > My short version is that we have two stages: >=20 > (1) Restore (at least) textual caller ID, i.e., caller name carried in = the SIP =46rom header, to the level of trustworthiness it generally had = in the pre-VoIP days. Since we cannot eliminate untrustworthy = participants in the system, we need to I don't think you meant it this way, but to be clear the SIP =46rom URI = display-name has never been trustworthy and receivers should never = blindly believe it. If we need to publish an RFC stating that, we can. = RFC 4474 almost went that far, but didn't for some reason. > (a) prevent on-path alteration That's not been a source of problems afaict. If it were, we'd have a = concern for STIR too - but we're not worried about malicious MITM for = STIR. We're worried about "bad ends". As an example of why we would = *not* want to prevent on-path alteration: we need to let carriers in the = middle remove any name assertion based on their knowledge the names are = incorrect or aren't trustworthy, or possibly replace it with what they = do know; but without impacting a calling number signed by STIR. > (b) indicate provenance of the information (e.g., was this inserted by = the caller, the caller's carrier or by the receiving carrier, = CNAM-style) I think that might be actually quite hard to accomplish, in a = trustworthy manner. The terminating carrier would know whether it got = the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it = doesn't know where the LIDB data ultimately came from other than the = LIDB AS for the calling number. Since the premise for this discussion is that calling names are not = trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their = data be populated by untrustworthy sources. Is that correct? > (c) possibly provide indications that allow the recipient to judge the = trustworthiness of the information, such as whether the information was = provided by the caller himself and whether the data was verified in some = way (e.g., by billing record or a third-party business database). Who generates this information, such that the terminating carrier (or = its customers) would believe it? If originating carriers would generate = it, or some set of trusted third parties - that's essentially what LIDB = is meant to be, no? In what way is LIDB broken such that a new solution = wouldn't be? > (2) Provide additional information, such as name and address of = organization or any licenses or registrations (e.g., licensed bank, = health care provider), to allow call recipients to filter or evaluate = calls, aided by third parties. Same question as (1-c) above. > In both cases, the goal is to reduce the opportunities for = impersonation-based fraud. (I'm intentionally saying "reduce", not = "eliminate".) The goal of this effort is *not* to reduce robocalls, = although some aspects of approach (2) may help there. It's still not clear what the existing/current problem is for calling = names, with enough clarity to figure out a solution to reduce it. Are = valid calling numbers being used with invalid names? How did the = invalid calling names get created/inserted such that terminating = carriers get them and believe they're valid? -hadriel From pogran@alum.mit.edu Mon Sep 2 10:43:38 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFA611E812C for ; Mon, 2 Sep 2013 10:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gJYQNeCNZ44 for ; Mon, 2 Sep 2013 10:43:33 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB3511E8139 for ; Mon, 2 Sep 2013 10:43:32 -0700 (PDT) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=QtNngzCd c=1 sm=0 tr=0 a=zyEqb+KCu+mIaNqjm1WFWQ==:117 a=H60vlihRZSsA:10 a=vc5lCoSdESQA:10 a=kj9zAlcOel0A:10 a=WRdS7oYUjucA:10 a=yPCof4ZbAAAA:8 a=8L35JRPKJVgWMgRl5kwA:9 a=zmoGsafMRzXfmZmA:21 a=VoNRaJ_C8986SzSE:21 a=CjuIK1q_8ugA:10 a=7DSvI1NPTFQA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=pogran@alum.mit.edu; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=pogran@alum.mit.edu; spf=softfail; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=pogran; auth=pass (LOGIN) Received-SPF: softfail (smtp02.rcn.cmh.synacor.com: transitional domain alum.mit.edu does not designate 72.93.100.146 as permitted sender) Received: from [72.93.100.146] ([72.93.100.146:52091] helo=[198.179.132.140]) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTPA id 26/4A-16085-14EC4225; Mon, 02 Sep 2013 13:43:30 -0400 User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Mon, 02 Sep 2013 13:43:26 -0400 From: Ken Pogran To: Hadriel Kaplan , Henning Schulzrinne Message-ID: Thread-Topic: [cnit] what's the actual problem here? In-Reply-To: <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 17:43:38 -0000 Hello, all. I am new to the group, but not to the subject matter. My name is Ken Pogran, and I'm with EGH, an OSS/BSS software firm in Lexington, Massachusetts that provides LIDB AS software (referred to by Hadriel) to the largest US Tier 1 service providers. I would like to respond to several of Hadriel's comments: On 9/2/13 11:51 AM, "Hadriel Kaplan" wrote: >>(b) indicate provenance of the information (e.g., was this inserted by >>the caller, the caller's carrier or by the receiving carrier, CNAM-style) > >I think that might be actually quite hard to accomplish, in a trustworthy >manner. The terminating carrier would know whether it got the name from >a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where >the LIDB data ultimately came from other than the LIDB AS for the calling >number. > >Since the premise for this discussion is that calling names are not >trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their >data be populated by untrustworthy sources. Is that correct? As it turns out, LIDB AS's are populated from multiple data sources, some potentially less trustworthy than others. LIDB's (and LIDB AS's) operated by the Tier 1 carriers will contain that carrier's own TN data, as well as data for the TNs of other service providers who are wholesale or "data storage" customers of the carrier's LIDB service. For the LIDB operator's own TN data, the source is the Tier 1 provider's CRM/subscriber management systems. And for wireline, these are typically legacy systems implementing processes that have been in place a good long time, with checks and balances and opportunities for human interaction to correct errors. That is probably as close as we get in LIDB today to trustworthy data. TN data for data storage customers is sourced by those other service providers (ILEC, CLEC, wireless, VoIP providers etc.). Their checks and balances on data quality won't necessarily be the same as those of the Tier 1's. >> (c) possibly provide indications that allow the recipient to judge the >>trustworthiness of the information, such as whether the information was >>provided by the caller himself and whether the data was verified in some >>way (e.g., by billing record or a third-party business database). > >Who generates this information, such that the terminating carrier (or its >customers) would believe it? If originating carriers would generate it, >or some set of trusted third parties - that's essentially what LIDB is >meant to be, no? In what way is LIDB broken such that a new solution >wouldn't be? I don't think LIDB is "broken" so much as the quality of data in LIDB will vary according to its source, as I noted above. And, as has been noted, lots of terminating carriers don't query LIDB, but instead query other databases. Some terminating carriers query LIDB in certain situations, but not others. Some non-LIDB CNAM databases derive CNAM strings from directory listings data, which is typically organized differently and, especially for business listings, may result in a different CNAM string from the one stored in the designated LIDB. It may not be quite as up-to-date as LIDB data populated directly from the subscriber management systems. I can't speak to practices of the independent LIDB providers. Hope this is helpful. Ken Pogran From Henning.Schulzrinne@fcc.gov Mon Sep 2 19:13:50 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D7421F9D9C for ; Mon, 2 Sep 2013 19:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AorvZyOFiPFO for ; Mon, 2 Sep 2013 19:13:46 -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 346B721F9E73 for ; Mon, 2 Sep 2013 19:13:45 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Stephen Farrell Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgABJAgD//75U4oAARwqAgAGrsyI= Date: Tue, 3 Sep 2013 02:13:43 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <5223A1A6.50507@cs.tcd.ie> , <5223A627.8080704@cs.tcd.ie> In-Reply-To: <5223A627.8080704@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 02:13:50 -0000 It's been widely available from all the typical residential local exchange = carriers, in the US, at least ten years for wireline, probably closer to 15= . Because of the way it's generated, via database lookup, it's not availabl= e for international calls.=0A= =0A= I can't speak for other countries.=0A= =0A= ________________________________________=0A= From: cnit-bounces@ietf.org [cnit-bounces@ietf.org] on behalf of Stephen Fa= rrell [stephen.farrell@cs.tcd.ie]=0A= Sent: Sunday, September 01, 2013 4:40 PM=0A= To: Henning Schulzrinne=0A= Cc: cnit@ietf.org=0A= Subject: Re: [cnit] what's the actual problem here?=0A= =0A= On 09/01/2013 09:31 PM, Henning Schulzrinne wrote:=0A= > See http://en.wikipedia.org/wiki/Caller_ID=0A= >=0A= > This has existed for landline phones since the early 1990s.=0A= =0A= Yes, I am familiar with seeing the caller's phone number=0A= presented, just not with names.=0A= =0A= > For cell phones, generally only the phone number is delivered,=0A= > although some carriers are now offering name delivery, for a fee.=0A= =0A= That's the bit I've not seen. The wiki page says that the names=0A= are mostly added by the recipient's telco, when a recipient pays=0A= for that service. (I'd imagine some EU data protection folks=0A= might have an interest in that btw - any idea if they've looked=0A= at it?)=0A= =0A= Also, does "now offering" imply this is a new-ish thing? If so,=0A= then I'm confused by your text saying a goal is to restore a=0A= level of confidence that's been damaged.=0A= From Henning.Schulzrinne@fcc.gov Mon Sep 2 19:22:25 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003FF21F9F88 for ; Mon, 2 Sep 2013 19:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkUXZ6aXC+fF for ; Mon, 2 Sep 2013 19:22:20 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 928CF21F9F4F for ; Mon, 2 Sep 2013 19:22:20 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "dcrocker@bbiw.net" Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgABRhQCAAalgfw== Date: Tue, 3 Sep 2013 02:22:18 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <5223A8CA.90402@dcrocker.net> In-Reply-To: <5223A8CA.90402@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 02:22:25 -0000 I'm not sure how you'd quantify this, but Ken's later message provides a go= od summary, I think. =0A= =0A= Two qualitative statements:=0A= =0A= (1) Almost all providers had processes in place that insured that the infor= mation was derived more or less directly from billing data.=0A= =0A= (2) The opportunities for end users to create callerID data that was malici= ously false were very limited.=0A= =0A= I'm not saying that nobody ever maliciously spoofed textual callerID in the= good old days, but sustained spoofing (without being quickly corrected) wo= uld have been difficult. Somebody would have had to impersonate a spoofing = target (presumably a reasonably well-known entity to be criminally useful) = in their business arrangements with a carrier.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Dave Crocker [dhc@dcrocker.net]=0A= Sent: Sunday, September 01, 2013 4:51 PM=0A= To: Henning Schulzrinne=0A= Cc: Stephen Farrell; cnit@ietf.org=0A= Subject: Re: [cnit] what's the actual problem here?=0A= =0A= On 9/1/2013 1:12 PM, Henning Schulzrinne wrote:=0A= > (1) Restore (at least) textual caller ID, i.e., caller name carried in th= e SIP From header, to the level of trustworthiness it generally had in the = pre-VoIP days=0A= =0A= =0A= Is there a description of what that original level of trustworthiness was?= =0A= =0A= d/=0A= =0A= --=0A= Dave Crocker=0A= Brandenburg InternetWorking=0A= bbiw.net=0A= From Henning.Schulzrinne@fcc.gov Mon Sep 2 19:26:18 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D042621F8618 for ; Mon, 2 Sep 2013 19:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAHvQPtrOGLO for ; Mon, 2 Sep 2013 19:26:13 -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 9B52421E8089 for ; Mon, 2 Sep 2013 19:26:13 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Hadriel Kaplan Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgAGP9QCAAG1edQ== Date: Tue, 3 Sep 2013 02:26:12 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> In-Reply-To: <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 02:26:19 -0000 This wasn't clearly stated, but what I meant was that the SIP display name = should be able to have (at least) the same level of trustworthiness as the = pre-VoIP textual callerID of a tier-1 carrier (obviously not delivered by S= IP at that time).=0A= =0A= ________________________________________=0A= From: Hadriel Kaplan [hadriel.kaplan@oracle.com]=0A= Sent: Monday, September 02, 2013 11:51 AM=0A= To: Henning Schulzrinne=0A= Cc: Stephen Farrell; cnit@ietf.org=0A= Subject: Re: [cnit] what's the actual problem here?=0A= =0A= On Sep 1, 2013, at 4:12 PM, Henning Schulzrinne wrote:=0A= =0A= > My short version is that we have two stages:=0A= >=0A= > (1) Restore (at least) textual caller ID, i.e., caller name carried in th= e SIP From header, to the level of trustworthiness it generally had in the = pre-VoIP days. Since we cannot eliminate untrustworthy participants in the = system, we need to=0A= =0A= I don't think you meant it this way, but to be clear the SIP From URI displ= ay-name has never been trustworthy and receivers should never blindly belie= ve it. If we need to publish an RFC stating that, we can. RFC 4474 almost= went that far, but didn't for some reason.=0A= =0A= =0A= -hadriel=0A= =0A= From Henning.Schulzrinne@fcc.gov Mon Sep 2 19:39:06 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9C821F9CC5 for ; Mon, 2 Sep 2013 19:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhw2zroFJ5tH for ; Mon, 2 Sep 2013 19:39:01 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADC721F9CB0 for ; Mon, 2 Sep 2013 19:38:59 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Hadriel Kaplan Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgAGP9QCAAG6Akg== Date: Tue, 3 Sep 2013 02:38:57 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> In-Reply-To: <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 02:39:06 -0000 I didn't want to get into solution space, but I'm a bit surprised by the qu= estion, since that's exactly what's been discussed, at length. The idea was= that, unlike today, the textual callerID is generally traceable to the ori= ginating carrier and/or originating entity, for the Organization/From split= I provided as an example earlier.=0A= =0A= As pointed out, that's not always true today, given that the destination ha= s no clue which database is being used and who inserted the information the= re - a tier-1 carrier based on business records, listyourself.net based on = caller assertion or some random white pages service based on who-knows.=0A= =0A= For the additional information, we have, as pointed out repeatedly, numerou= s third-party databases, both private and governmental. The originating car= rier or possibly the originator can obtain and sign that information as a v= alue-add. The ARID approach is another possibility.=0A= =0A= I've tried to provide very specific examples of how this could work, but am= obviously not getting the point across.=0A= =0A= ________________________________________=0A= From: Hadriel Kaplan [hadriel.kaplan@oracle.com]=0A= Sent: Monday, September 02, 2013 11:51 AM=0A= To: Henning Schulzrinne=0A= Cc: Stephen Farrell; cnit@ietf.org=0A= Subject: Re: [cnit] what's the actual problem here?=0A= =0A= =0A= > (b) indicate provenance of the information (e.g., was this inserted by th= e caller, the caller's carrier or by the receiving carrier, CNAM-style)=0A= =0A= I think that might be actually quite hard to accomplish, in a trustworthy m= anner. The terminating carrier would know whether it got the name from a L= IDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where the = LIDB data ultimately came from other than the LIDB AS for the calling numbe= r.=0A= =0A= Since the premise for this discussion is that calling names are not trustwo= rthy anymore (?), I'm assuming the LIDB AS'es are letting their data be pop= ulated by untrustworthy sources. Is that correct?=0A= =0A= =0A= =0A= -hadriel=0A= =0A= From br@brianrosen.net Tue Sep 3 06:18:18 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF91421E814C for ; Tue, 3 Sep 2013 06:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.269 X-Spam-Level: X-Spam-Status: No, score=-103.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F73dyOi4hTPQ for ; Tue, 3 Sep 2013 06:18:14 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4721E8151 for ; Tue, 3 Sep 2013 06:18:14 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id f11so1290367qae.9 for ; Tue, 03 Sep 2013 06:18:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=5fFKfgGAZEb4rUI+Hiw/dLYEa1i3GxuDfQYjxe4CYRQ=; b=l84lP4J/h3iUohsJG6mLAHvE7UNtUDAGWic4cIZUDctqNna4gcRAouyU+Jnxlk3vpF wJUENAacXSQn4oUSi4ekJkeppOJRZgW/5BI2pca11iF+m3s+kf0S7eT4dJCjd6WT/ROc O3ZcM6lnjjzo5MKPe8oNwV0z1UntbyqfXqnnCSKDncepO+AVgCVIXmyN4tHLHS8Pk6Hk 9kci5Tg9/aZHBRlI1Fl9MGt0xka/HCT9mr2EJBfFhO/UIvuRwtLGs5gpqhCFsjileIsy FBgoxwBt4AixXyzph02yWgVqtIcgb7HFN9SeO1TpXUH+Whb39h336Cwory1lBjfx3FdK r+Qg== X-Gm-Message-State: ALoCoQnEZyhDnlopogP3OQHjqW1s92rUZpi3tgceBGKSDcwzPOnzLw5AFyoS2oX+GEbCmn+7xMCr X-Received: by 10.49.134.102 with SMTP id pj6mr10303456qeb.49.1378214293718; Tue, 03 Sep 2013 06:18:13 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id t1sm21018549qeu.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 06:18:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <5EC50FD3-FD06-499A-BD01-9BC3FFFA5025@att.com> Date: Tue, 3 Sep 2013 09:18:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> <521D53D9.2080008@alum.mit.edu> <15603CA4-534A-4CCB-9EC4-9EFFD17B8B47@brianrosen.net> <4B1956260CD29F4A9622F00322FE053193812973E1@BOBO1A.bobotek.net> <5CD91A23-CB33-47B6-9173-A8C5B62F7E40@oracle.com> <7EB0D650-FFF9-459B-8D14-CBD09871D44B@brianrosen.net> <52207A27.5010105@bbn.com> <0E552CE9-DE70-4B45-B230-EC9E68DDCDDE@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA3012B1526AD@FHDP! 1LUMXC7V31.us.one.verizon.com> <9D3DF6A2-F2F0-4766-B9B3-EBCBAB3C4299@oracle.com> <5220D5DB.8050804@dcrocker.net > <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.n! et>, <52224580.6030901@dcrocker.net> <5EC50FD3-FD06-499A-BD01-9BC3FFFA5025@att.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Stephen Kent , Henning Schulzrinne , "" , "Dwight, Timothy M \(Tim\)" Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 13:18:19 -0000 No, AFAIK, it's not your data. There is no NPAC data in there, for = example. Brian On Sep 1, 2013, at 6:10 AM, "DOLLY, MARTIN C" wrote: > Brian >=20 > Your DB? With our data.... >=20 > Martin Dolly > Lead Member of Technical Staff > Core Network & Gov't/Regulatory Standards =20 > AT&T Labs - Network Technology > +1-609-903-3360 > md3135@att.com >=20 > On Aug 31, 2013, at 3:36 PM, "Dave Crocker" wrote: >=20 >> On 8/30/2013 10:40 AM, Brian Rosen wrote: >>> Okay. We support dozens of customers who had serious fraud abuse >>> until they started using our database to evaluate callers to their >>> call center. >>=20 >> OK. Good starting point. Call centers represent specialized user = organizations, with operators have some distinct skills and training, = but a useful reference. If the intended scope of the current work is... = everyone in the world... then there are some issues in generalizing the = experience from a few dozen skilled user organizations to billions of = individual users. But, again, a good starting point. >>=20 >>=20 >>> Typically, they query with 3-6 fields. They get a >>> score back. They decide how to handle the caller based on the = score. >>=20 >> I assume that the call center operators have established procedures, = rather than creating an action based personal whim of the moment. Again, = this would distinguish them from typical, mass-market end users. >>=20 >>=20 >>> The part of this that I can't cite a specific example for is what >>> some clever UI developer will come up with to use the data. >>=20 >> Unfortunately that part of the equation matters. Not necessarily the = fine-grained detail, but the basic expectations of how information will = get used and by whom and whether it is pre-determined or decided in = real-time. >>=20 >> That's why I am trying to distinguish between an architectural = component that implements policies -- the same as the filtering engine = in email anti-abuse systems today -- versus assumptions that end-users = will be making real-time decisions, largely based on raw information. >>=20 >> In fact, the essential difference is between having a software policy = engine with built-in rulesets, versus a 'wet' real-time policy = formulation engine. >>=20 >>=20 >>> What I >>> know is, it's useful, and we'll figure out a way. >>=20 >> Then you know more than I do, in spite of my background in usability = design and the considerable industry experience in this space, which = frankly encourages caution in this realm. >>=20 >>=20 >>> It might have >>> binned responses. It might change the response if this is the first >>> call from the identity. It might supply a thumbs up/down selection >>> that is used for other callers. It might supply a Travelocity style >>> rating. >>=20 >> So it turns out that what you've described is considerably more than = clever UI design. >>=20 >> You've describe the effects of a policy engine that does its own = analysis and handling decisions. And indeed, that's exactly the = distinction I'm suggesting for this work. With luck, that means we're = disagreeing on some terminology, rather than some architecture. >>=20 >> However, this is not a small point. It is a key architectural = component and designing for that function, rather than designing for = end-users, per se, is a fundamental difference. >>=20 >>=20 >>=20 >> d/ >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit From br@brianrosen.net Tue Sep 3 10:32:58 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66E221E815A for ; Tue, 3 Sep 2013 10:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DHJyl18anWX for ; Tue, 3 Sep 2013 10:32:54 -0700 (PDT) Received: from mail-yh0-f51.google.com (mail-yh0-f51.google.com [209.85.213.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3D87A21E8146 for ; Tue, 3 Sep 2013 10:32:54 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id t59so1151599yho.24 for ; Tue, 03 Sep 2013 10:32:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=mZNs6vJ2ZKtXJCCe6z6Giq+CD4lQ3U7ysFROqliW5Yc=; b=j0LRgGLYzUu2M/cBc/ZZKGAwrjKP2XyqTzOQlgWsfUxz82SXizvOaLLhlPp7xoo9Cd T+iWkQxcnk2wWEhctHNvwn3hHM5svglwQvC+ntTlpZL6s0UJUiQaXUsoNRLHiqVmeOaD poNQRBuak3eB4ECrAZnszhFi9dwymLsiyJE9NkYUfG82OgE/DgNkMBdG0QVu5uduUKPS kaolQzatyUIA2xgy6yzCnIcQim81bYV6qFwPlCyLIcVAI8DPJWfxiurlrjO+5niCs3hn 3hbCbWWGdAl68VNpSoq1GNiZP0Vs1iiAjXOLridgC0FJ3mEpwY9rFKKrBlN/dU0ZRV0A 3EVQ== X-Gm-Message-State: ALoCoQnofS4jHjKkbPy76IF8xmpMEPNAo/JPnu59cGA3BpSco51BTjJsn+k4csI0leaggwpRT9Hv X-Received: by 10.236.100.144 with SMTP id z16mr28109692yhf.9.1378229573695; Tue, 03 Sep 2013 10:32:53 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 48sm23843536yhq.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 10:32:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: Date: Tue, 3 Sep 2013 13:32:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Hadriel Kaplan , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 17:32:59 -0000 I'm going to try and restate the "what is the problem", working off what = has been said. In the PSTN today, there is an optional service that will display the = name of the caller. The name is currently obtained from a database. = Historically, the database is operated by the originating carrier, and = is populated with the name obtained from the billing and service data = used to establish the service. The database is queried by the = terminating carrier with the phone number to obtain the name. Recently, = due to charges levied on the terminating carrier by the originating = carrier to query the database, alternatives have arose where large = consumer oriented databases are queried that independently match name = with telephone number without reference to the originating carrier's = information. When the databases were operated by large established = telcos, the reliability of the data was good. However, some service = providers are now lax in how the data is populated, and some even = advertise the ability to allow any name to be used with a number. This = has significantly eroded the usefulness of the service. Where caller = name service is provided, it replaces the display of the calling party = number, although smart phones will usually substitute their local = contact list name for whatever is provided by the calling name service. = This means that if stir succeeds in improving the quality of the calling = party number, but no solution is provided for calling party name, = fraudsters may still be able to disguise their activities. This work proposes to change how caller name is carried to using the = existing display name portion of the SIP URI in the =46rom or P-A-I = field. The name would be carried in the signaling from origination to = termination. This capability exists today, although the service = providers typically do not restrict or asses what name the caller = asserts. Therefore, along with the name would come a form of validation = that the name is genuine, and, for calls from businesses, the type of = business it is from. =20 Validation of names is exceedingly difficult, and this work does not = propose a solution that will provide a name with absolute certainty that = it is genuine and associated with the telephone number of the calling = party. It does propose that the data be vetted through some process, = which may not result in a simple "this is the name" result. Rather, the = vetting process may provide a name, but accompany it with a confidence = factor(score) indicating the source's assessment of the likelihood that = the name is represents the calling party. Confidence would be a simple = 0-100 scaler, without an attempt to precisely define or normalize it = between sources. That means that the termination side would have to = evaluate the confidence factor and the source of the confidence together = to decide how much to trust the name. The termination could take a = variety of actions based on the source and the claimed confidence. = Doing so implies that the number of sources is limited so that = evaluating the source for trustworthiness can be accomplished. =20 Vetting the name at the source is more likely to be of value, because = the source may have a variety of other information about the party the = name is assigned to that can be used to improve the reliability of the = vetting process. For example, address, other phone numbers, age, email = addresses, domains (for businesses), etc can be used to provide much = higher confidence that the name accurately represents the calling party = than just the number known at the termination side. Besides the name, when a call is made from a business, the type of = business can provide important information to the caller when deciding = to answer the call, or trust the caller. The type of business would be = a selection from an existing taxonomy of business types and would be = relatively high level ("bank", "florist", "doctor").=20 The name, type of business (if appropriate), the source of the data, the = confidence indicator and some indication of the vetting process would = accompany the name in a new header in a secure manner -- secure in the = sense that the number, the name, type, the source, and the sources' = asserted confidence of the name is signed by the source.=20 If the termination side did not trust the source, or it did, but the = confidence was too low in its opinion, the termination may take a number = of actions, including, but not limited to: a) Refuse the call, or send it to voicemail b) Use an independent source of names, like the alternative name = suppliers that exist today to display an alternate name c) Provide a visual or audible warning to the user that the name may not = be valid d) Provide a visual or audible representation of the confidence, = possibly simplified (red/orange/yellow/green) e) Provide a caller feedback (thumbs up/down) mechanism to further = develop a rating of the source, or the specific name/number pair Brian On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne = wrote: > I didn't want to get into solution space, but I'm a bit surprised by = the question, since that's exactly what's been discussed, at length. The = idea was that, unlike today, the textual callerID is generally traceable = to the originating carrier and/or originating entity, for the = Organization/=46rom split I provided as an example earlier. >=20 > As pointed out, that's not always true today, given that the = destination has no clue which database is being used and who inserted = the information there - a tier-1 carrier based on business records, = listyourself.net based on caller assertion or some random white pages = service based on who-knows. >=20 > For the additional information, we have, as pointed out repeatedly, = numerous third-party databases, both private and governmental. The = originating carrier or possibly the originator can obtain and sign that = information as a value-add. The ARID approach is another possibility. >=20 > I've tried to provide very specific examples of how this could work, = but am obviously not getting the point across. >=20 > ________________________________________ > From: Hadriel Kaplan [hadriel.kaplan@oracle.com] > Sent: Monday, September 02, 2013 11:51 AM > To: Henning Schulzrinne > Cc: Stephen Farrell; cnit@ietf.org > Subject: Re: [cnit] what's the actual problem here? >=20 >=20 >> (b) indicate provenance of the information (e.g., was this inserted = by the caller, the caller's carrier or by the receiving carrier, = CNAM-style) >=20 > I think that might be actually quite hard to accomplish, in a = trustworthy manner. The terminating carrier would know whether it got = the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it = doesn't know where the LIDB data ultimately came from other than the = LIDB AS for the calling number. >=20 > Since the premise for this discussion is that calling names are not = trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their = data be populated by untrustworthy sources. Is that correct? >=20 >=20 >=20 > -hadriel >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From pkyzivat@alum.mit.edu Tue Sep 3 12:31:26 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD6621F87D1 for ; Tue, 3 Sep 2013 12:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.042 X-Spam-Level: X-Spam-Status: No, score=-0.042 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYXyUkUEzgLs for ; Tue, 3 Sep 2013 12:31:22 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 1203821F8438 for ; Tue, 3 Sep 2013 12:31:20 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id Lbqx1m0041vXlb856jXLzq; Tue, 03 Sep 2013 19:31:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id LjXK1m01x3ZTu2S3djXLvj; Tue, 03 Sep 2013 19:31:20 +0000 Message-ID: <52263907.4050602@alum.mit.edu> Date: Tue, 03 Sep 2013 15:31:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: cnit@ietf.org References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> In-Reply-To: <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378236680; bh=jJkq/9GGW9So+Mz1vBuGRhoCWDDRS2Cwuyg5A0zk9yY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GbZifwPsAEP0Im9ZB6EA1JbJTMPWCgj2rkbDGYAnuZ1W+kxIHUKC7AD2smhp6+KPw dqzKQkNjMpRK9lEFcbRsXZqcOMCZ3azP8J6GFUBFbR1HfsChZ5LSz4dc//g+Wz5b1M QeJ/esu4MCXqXiewxRt9Q8telOPofiy2A/2TBcQsUlOTQLwGT8ZbymY+XuKWQOv+xA nnoHSc5gy3KhBQ85ck6IIXXtLZSiCy87ADEO4O0PKZ+inywSTEhi5fYmPsfp4dZ7aK IIfZoAowDDuLmLrURtRp2s/4rQIdDqvkxsLfGNoRTV+HPY9l7z4o0o3Ie85CnUFbg+ T1RNlz9bugliA== Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 19:31:26 -0000 Nits: s/arose/arisen/ s/scaler/scalar/ Substance: I'm still not buying the trust chain that says: - caller supplies the name - caller's provider provides the validation of the name, using an undefined method and scale - callee decides how to trust the name based on the provided score and trust in the signer Thanks, Paul On 9/3/13 1:32 PM, Brian Rosen wrote: > I'm going to try and restate the "what is the problem", working off what has been said. > > In the PSTN today, there is an optional service that will display the name of the caller. The name is currently obtained from a database. Historically, the database is operated by the originating carrier, and is populated with the name obtained from the billing and service data used to establish the service. The database is queried by the terminating carrier with the phone number to obtain the name. Recently, due to charges levied on the terminating carrier by the originating carrier to query the database, alternatives have arose where large consumer oriented databases are queried that independently match name with telephone number without reference to the originating carrier's information. When the databases were operated by large established telcos, the reliability of the data was good. However, some service providers are now lax in how the data is populated, and some even advertise the ability to allow any name to be used with a number. This has significantly erod ed > the usefulness of the service. Where caller name service is provided, it replaces the display of the calling party number, although smart phones will usually substitute their local contact list name for whatever is provided by the calling name service. This means that if stir succeeds in improving the quality of the calling party number, but no solution is provided for calling party name, fraudsters may still be able to disguise their activities. > > This work proposes to change how caller name is carried to using the existing display name portion of the SIP URI in the From or P-A-I field. The name would be carried in the signaling from origination to termination. This capability exists today, although the service providers typically do not restrict or asses what name the caller asserts. Therefore, along with the name would come a form of validation that the name is genuine, and, for calls from businesses, the type of business it is from. > > Validation of names is exceedingly difficult, and this work does not propose a solution that will provide a name with absolute certainty that it is genuine and associated with the telephone number of the calling party. It does propose that the data be vetted through some process, which may not result in a simple "this is the name" result. Rather, the vetting process may provide a name, but accompany it with a confidence factor(score) indicating the source's assessment of the likelihood that the name is represents the calling party. Confidence would be a simple 0-100 scaler, without an attempt to precisely define or normalize it between sources. That means that the termination side would have to evaluate the confidence factor and the source of the confidence together to decide how much to trust the name. The termination could take a variety of actions based on the source and the claimed confidence. Doing so implies that the number of sources is limited so that evaluati ng > the source for trustworthiness can be accomplished. > > Vetting the name at the source is more likely to be of value, because the source may have a variety of other information about the party the name is assigned to that can be used to improve the reliability of the vetting process. For example, address, other phone numbers, age, email addresses, domains (for businesses), etc can be used to provide much higher confidence that the name accurately represents the calling party than just the number known at the termination side. > > Besides the name, when a call is made from a business, the type of business can provide important information to the caller when deciding to answer the call, or trust the caller. The type of business would be a selection from an existing taxonomy of business types and would be relatively high level ("bank", "florist", "doctor"). > > The name, type of business (if appropriate), the source of the data, the confidence indicator and some indication of the vetting process would accompany the name in a new header in a secure manner -- secure in the sense that the number, the name, type, the source, and the sources' asserted confidence of the name is signed by the source. > > If the termination side did not trust the source, or it did, but the confidence was too low in its opinion, the termination may take a number of actions, including, but not limited to: > a) Refuse the call, or send it to voicemail > b) Use an independent source of names, like the alternative name suppliers that exist today to display an alternate name > c) Provide a visual or audible warning to the user that the name may not be valid > d) Provide a visual or audible representation of the confidence, possibly simplified (red/orange/yellow/green) > e) Provide a caller feedback (thumbs up/down) mechanism to further develop a rating of the source, or the specific name/number pair > > Brian > > > On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: > >> I didn't want to get into solution space, but I'm a bit surprised by the question, since that's exactly what's been discussed, at length. The idea was that, unlike today, the textual callerID is generally traceable to the originating carrier and/or originating entity, for the Organization/From split I provided as an example earlier. >> >> As pointed out, that's not always true today, given that the destination has no clue which database is being used and who inserted the information there - a tier-1 carrier based on business records, listyourself.net based on caller assertion or some random white pages service based on who-knows. >> >> For the additional information, we have, as pointed out repeatedly, numerous third-party databases, both private and governmental. The originating carrier or possibly the originator can obtain and sign that information as a value-add. The ARID approach is another possibility. >> >> I've tried to provide very specific examples of how this could work, but am obviously not getting the point across. >> >> ________________________________________ >> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >> Sent: Monday, September 02, 2013 11:51 AM >> To: Henning Schulzrinne >> Cc: Stephen Farrell; cnit@ietf.org >> Subject: Re: [cnit] what's the actual problem here? >> >> >>> (b) indicate provenance of the information (e.g., was this inserted by the caller, the caller's carrier or by the receiving carrier, CNAM-style) >> >> I think that might be actually quite hard to accomplish, in a trustworthy manner. The terminating carrier would know whether it got the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where the LIDB data ultimately came from other than the LIDB AS for the calling number. >> >> Since the premise for this discussion is that calling names are not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their data be populated by untrustworthy sources. Is that correct? >> >> >> >> -hadriel >> >> _______________________________________________ >> 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 > From br@brianrosen.net Tue Sep 3 12:36:57 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B345421F9F21 for ; Tue, 3 Sep 2013 12:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKnM4F7cS6I4 for ; Tue, 3 Sep 2013 12:36:52 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0A18A21F9F3A for ; Tue, 3 Sep 2013 12:36:41 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so6237892obc.40 for ; Tue, 03 Sep 2013 12:36:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=D8Wb4UQpYWnc9Eqhk6exx9CTu/8RFassWajVGb7zzRs=; b=EhcwouSR5PYh4Ydg3nnEORk6gY6nKw3hPa9PgVW+6OsG7KdcmQVZqHkCXO7452MAUU y7uiywIrqRL5SzDOQpgdiy9DZh5LgKSkw1j4JSwjG+wR3AkCODTiwTJ+diXVjeH29279 Y4D6fKoXwYQ3RGQ2ubU+F5rq7rJpvaPHZVcc74z5TUqIOYRZuFF86DwyeD4hVR/VhHVq PEWkwkEnqgBNKY7DI37XopHcvIRG6tNg3GrtO17yzXqt6YnJBfQyVrVTk4uVM4mHoAay GfrwIt2hEcdRw8qSNPIZVs6qK0Q9NO3A48Xd7hvLOmUhb+slFcLOIIfTSXFeuwhUUkE/ tVnA== X-Gm-Message-State: ALoCoQko+sUewEcHVLFD9HU6RQYeURE2vxVBnP7l1JvHGASrVvo5FoE0kYVt00KQh0FM5RBed1AO X-Received: by 10.182.250.232 with SMTP id zf8mr22083567obc.75.1378236997372; Tue, 03 Sep 2013 12:36:37 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id bq4sm19841089obb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 12:36:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <52263907.4050602@alum.mit.edu> Date: Tue, 3 Sep 2013 15:36:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 19:36:57 -0000 Henning proposed to have some standardization of "method", but he meant = broad categories like "from billing records". That probably doesn't = help you, but I liked that idea. Without the validation, how would we change anything? As it exists now, = both the display name, if sent, and the content of the CNAM database can = easily be anything you want if you use a pink carrier. How would you = propose to fix that? Brian On Sep 3, 2013, at 3:31 PM, Paul Kyzivat wrote: > Nits: >=20 > s/arose/arisen/ > s/scaler/scalar/ >=20 > Substance: >=20 > I'm still not buying the trust chain that says: >=20 > - caller supplies the name > - caller's provider provides the validation of the name, > using an undefined method and scale > - callee decides how to trust the name based on the > provided score and trust in the signer >=20 > Thanks, > Paul >=20 > On 9/3/13 1:32 PM, Brian Rosen wrote: >> I'm going to try and restate the "what is the problem", working off = what has been said. >>=20 >> In the PSTN today, there is an optional service that will display the = name of the caller. The name is currently obtained from a database. = Historically, the database is operated by the originating carrier, and = is populated with the name obtained from the billing and service data = used to establish the service. The database is queried by the = terminating carrier with the phone number to obtain the name. Recently, = due to charges levied on the terminating carrier by the originating = carrier to query the database, alternatives have arose where large = consumer oriented databases are queried that independently match name = with telephone number without reference to the originating carrier's = information. When the databases were operated by large established = telcos, the reliability of the data was good. However, some service = providers are now lax in how the data is populated, and some even = advertise the ability to allow any name to be used with a number. This = has significantly erod > ed >> the usefulness of the service. Where caller name service is = provided, it replaces the display of the calling party number, although = smart phones will usually substitute their local contact list name for = whatever is provided by the calling name service. This means that if = stir succeeds in improving the quality of the calling party number, but = no solution is provided for calling party name, fraudsters may still be = able to disguise their activities. >>=20 >> This work proposes to change how caller name is carried to using the = existing display name portion of the SIP URI in the =46rom or P-A-I = field. The name would be carried in the signaling from origination to = termination. This capability exists today, although the service = providers typically do not restrict or asses what name the caller = asserts. Therefore, along with the name would come a form of validation = that the name is genuine, and, for calls from businesses, the type of = business it is from. >>=20 >> Validation of names is exceedingly difficult, and this work does not = propose a solution that will provide a name with absolute certainty that = it is genuine and associated with the telephone number of the calling = party. It does propose that the data be vetted through some process, = which may not result in a simple "this is the name" result. Rather, the = vetting process may provide a name, but accompany it with a confidence = factor(score) indicating the source's assessment of the likelihood that = the name is represents the calling party. Confidence would be a simple = 0-100 scaler, without an attempt to precisely define or normalize it = between sources. That means that the termination side would have to = evaluate the confidence factor and the source of the confidence together = to decide how much to trust the name. The termination could take a = variety of actions based on the source and the claimed confidence. = Doing so implies that the number of sources is limited so that evaluati > ng >> the source for trustworthiness can be accomplished. >>=20 >> Vetting the name at the source is more likely to be of value, because = the source may have a variety of other information about the party the = name is assigned to that can be used to improve the reliability of the = vetting process. For example, address, other phone numbers, age, email = addresses, domains (for businesses), etc can be used to provide much = higher confidence that the name accurately represents the calling party = than just the number known at the termination side. >>=20 >> Besides the name, when a call is made from a business, the type of = business can provide important information to the caller when deciding = to answer the call, or trust the caller. The type of business would be = a selection from an existing taxonomy of business types and would be = relatively high level ("bank", "florist", "doctor"). >>=20 >> The name, type of business (if appropriate), the source of the data, = the confidence indicator and some indication of the vetting process = would accompany the name in a new header in a secure manner -- secure in = the sense that the number, the name, type, the source, and the sources' = asserted confidence of the name is signed by the source. >>=20 >> If the termination side did not trust the source, or it did, but the = confidence was too low in its opinion, the termination may take a number = of actions, including, but not limited to: >> a) Refuse the call, or send it to voicemail >> b) Use an independent source of names, like the alternative name = suppliers that exist today to display an alternate name >> c) Provide a visual or audible warning to the user that the name may = not be valid >> d) Provide a visual or audible representation of the confidence, = possibly simplified (red/orange/yellow/green) >> e) Provide a caller feedback (thumbs up/down) mechanism to further = develop a rating of the source, or the specific name/number pair >>=20 >> Brian >>=20 >>=20 >> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne = wrote: >>=20 >>> I didn't want to get into solution space, but I'm a bit surprised by = the question, since that's exactly what's been discussed, at length. The = idea was that, unlike today, the textual callerID is generally traceable = to the originating carrier and/or originating entity, for the = Organization/=46rom split I provided as an example earlier. >>>=20 >>> As pointed out, that's not always true today, given that the = destination has no clue which database is being used and who inserted = the information there - a tier-1 carrier based on business records, = listyourself.net based on caller assertion or some random white pages = service based on who-knows. >>>=20 >>> For the additional information, we have, as pointed out repeatedly, = numerous third-party databases, both private and governmental. The = originating carrier or possibly the originator can obtain and sign that = information as a value-add. The ARID approach is another possibility. >>>=20 >>> I've tried to provide very specific examples of how this could work, = but am obviously not getting the point across. >>>=20 >>> ________________________________________ >>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>> Sent: Monday, September 02, 2013 11:51 AM >>> To: Henning Schulzrinne >>> Cc: Stephen Farrell; cnit@ietf.org >>> Subject: Re: [cnit] what's the actual problem here? >>>=20 >>>=20 >>>> (b) indicate provenance of the information (e.g., was this inserted = by the caller, the caller's carrier or by the receiving carrier, = CNAM-style) >>>=20 >>> I think that might be actually quite hard to accomplish, in a = trustworthy manner. The terminating carrier would know whether it got = the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it = doesn't know where the LIDB data ultimately came from other than the = LIDB AS for the calling number. >>>=20 >>> Since the premise for this discussion is that calling names are not = trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their = data be populated by untrustworthy sources. Is that correct? >>>=20 >>>=20 >>>=20 >>> -hadriel >>>=20 >>> _______________________________________________ >>> cnit mailing list >>> cnit@ietf.org >>> https://www.ietf.org/mailman/listinfo/cnit >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >>=20 >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From pkyzivat@alum.mit.edu Tue Sep 3 12:54:53 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0748A21F9F00 for ; Tue, 3 Sep 2013 12:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.041 X-Spam-Level: X-Spam-Status: No, score=-0.041 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8q3qRvuOWqI for ; Tue, 3 Sep 2013 12:54:48 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 660F921F9FF9 for ; Tue, 3 Sep 2013 12:54:48 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id Lbo51m0031vXlb856junjl; Tue, 03 Sep 2013 19:54:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id Ljun1m00k3ZTu2S3djunlN; Tue, 03 Sep 2013 19:54:47 +0000 Message-ID: <52263E86.3020403@alum.mit.edu> Date: Tue, 03 Sep 2013 15:54:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> In-Reply-To: <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378238087; bh=05wVXoCS8x/HtS20xikBBcwUgVow/AdptqwauL2qrm8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ELKxJUkwLmi0wsUDNgVOojBbIr7FULsQ3qdx4LgQaU7X5Vt/VVE1lmW0+TJQ+MIhX Mfk7Y6ttAmf7qFlxPibY/DlulSaIrJ63n5t227cCyJ5wCYPa5pHDBUoXrQGhWuNmLC TywDKNM2BvcOTgNnadONfM52nWcCmRZkwPGwFV+Al/Uu52Zfphi/uq92vjJNIWtQDl fSbEUdnPZfYjsgj1KfwEEByDlhXgd1bFf/BtnEX1NLclDpOncjgfth5wgY1Oeo//ei nYruf5PwowKFkkzT6T7CchzJswYfaUvUh4LH6OkVysW0Zv3YKj5jiuqOQf6aQ3RcAH Lo439a8MElxBw== Cc: cnit@ietf.org Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 19:54:53 -0000 On 9/3/13 3:36 PM, Brian Rosen wrote: > Henning proposed to have some standardization of "method", but he meant broad categories like "from billing records". That probably doesn't help you, but I liked that idea. > > Without the validation, how would we change anything? As it exists now, both the display name, if sent, and the content of the CNAM database can easily be anything you want if you use a pink carrier. How would you propose to fix that? As a user of this service, I would be more comfortable with it done by an agent for the callee, based on number lookup. At least then the callee has somebody to blame, and hopefully can choose which one. At least this way the callee has a contract with *somebody* that will say *something* about the level of trust in the data, and a recourse if it turns out to be wrong. I'm imagining that companies like Neustar would offer this service, either directly to the end user, or to the provider for the callee. And companies like Google might also provide a service like this. The interface to the service need not be standardized. On smart phones you could install a call validation app that plugs into incoming call handling, and manages its own display of the information. Thanks, Paul > Brian > > On Sep 3, 2013, at 3:31 PM, Paul Kyzivat wrote: > >> Nits: >> >> s/arose/arisen/ >> s/scaler/scalar/ >> >> Substance: >> >> I'm still not buying the trust chain that says: >> >> - caller supplies the name >> - caller's provider provides the validation of the name, >> using an undefined method and scale >> - callee decides how to trust the name based on the >> provided score and trust in the signer >> >> Thanks, >> Paul >> >> On 9/3/13 1:32 PM, Brian Rosen wrote: >>> I'm going to try and restate the "what is the problem", working off what has been said. >>> >>> In the PSTN today, there is an optional service that will display the name of the caller. The name is currently obtained from a database. Historically, the database is operated by the originating carrier, and is populated with the name obtained from the billing and service data used to establish the service. The database is queried by the terminating carrier with the phone number to obtain the name. Recently, due to charges levied on the terminating carrier by the originating carrier to query the database, alternatives have arose where large consumer oriented databases are queried that independently match name with telephone number without reference to the originating carrier's information. When the databases were operated by large established telcos, the reliability of the data was good. However, some service providers are now lax in how the data is populated, and some even advertise the ability to allow any name to be used with a number. This has significantly er od >> ed >>> the usefulness of the service. Where caller name service is provided, it replaces the display of the calling party number, although smart phones will usually substitute their local contact list name for whatever is provided by the calling name service. This means that if stir succeeds in improving the quality of the calling party number, but no solution is provided for calling party name, fraudsters may still be able to disguise their activities. >>> >>> This work proposes to change how caller name is carried to using the existing display name portion of the SIP URI in the From or P-A-I field. The name would be carried in the signaling from origination to termination. This capability exists today, although the service providers typically do not restrict or asses what name the caller asserts. Therefore, along with the name would come a form of validation that the name is genuine, and, for calls from businesses, the type of business it is from. >>> >>> Validation of names is exceedingly difficult, and this work does not propose a solution that will provide a name with absolute certainty that it is genuine and associated with the telephone number of the calling party. It does propose that the data be vetted through some process, which may not result in a simple "this is the name" result. Rather, the vetting process may provide a name, but accompany it with a confidence factor(score) indicating the source's assessment of the likelihood that the name is represents the calling party. Confidence would be a simple 0-100 scaler, without an attempt to precisely define or normalize it between sources. That means that the termination side would have to evaluate the confidence factor and the source of the confidence together to decide how much to trust the name. The termination could take a variety of actions based on the source and the claimed confidence. Doing so implies that the number of sources is limited so that evalua ti >> ng >>> the source for trustworthiness can be accomplished. >>> >>> Vetting the name at the source is more likely to be of value, because the source may have a variety of other information about the party the name is assigned to that can be used to improve the reliability of the vetting process. For example, address, other phone numbers, age, email addresses, domains (for businesses), etc can be used to provide much higher confidence that the name accurately represents the calling party than just the number known at the termination side. >>> >>> Besides the name, when a call is made from a business, the type of business can provide important information to the caller when deciding to answer the call, or trust the caller. The type of business would be a selection from an existing taxonomy of business types and would be relatively high level ("bank", "florist", "doctor"). >>> >>> The name, type of business (if appropriate), the source of the data, the confidence indicator and some indication of the vetting process would accompany the name in a new header in a secure manner -- secure in the sense that the number, the name, type, the source, and the sources' asserted confidence of the name is signed by the source. >>> >>> If the termination side did not trust the source, or it did, but the confidence was too low in its opinion, the termination may take a number of actions, including, but not limited to: >>> a) Refuse the call, or send it to voicemail >>> b) Use an independent source of names, like the alternative name suppliers that exist today to display an alternate name >>> c) Provide a visual or audible warning to the user that the name may not be valid >>> d) Provide a visual or audible representation of the confidence, possibly simplified (red/orange/yellow/green) >>> e) Provide a caller feedback (thumbs up/down) mechanism to further develop a rating of the source, or the specific name/number pair >>> >>> Brian >>> >>> >>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: >>> >>>> I didn't want to get into solution space, but I'm a bit surprised by the question, since that's exactly what's been discussed, at length. The idea was that, unlike today, the textual callerID is generally traceable to the originating carrier and/or originating entity, for the Organization/From split I provided as an example earlier. >>>> >>>> As pointed out, that's not always true today, given that the destination has no clue which database is being used and who inserted the information there - a tier-1 carrier based on business records, listyourself.net based on caller assertion or some random white pages service based on who-knows. >>>> >>>> For the additional information, we have, as pointed out repeatedly, numerous third-party databases, both private and governmental. The originating carrier or possibly the originator can obtain and sign that information as a value-add. The ARID approach is another possibility. >>>> >>>> I've tried to provide very specific examples of how this could work, but am obviously not getting the point across. >>>> >>>> ________________________________________ >>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>> Sent: Monday, September 02, 2013 11:51 AM >>>> To: Henning Schulzrinne >>>> Cc: Stephen Farrell; cnit@ietf.org >>>> Subject: Re: [cnit] what's the actual problem here? >>>> >>>> >>>>> (b) indicate provenance of the information (e.g., was this inserted by the caller, the caller's carrier or by the receiving carrier, CNAM-style) >>>> >>>> I think that might be actually quite hard to accomplish, in a trustworthy manner. The terminating carrier would know whether it got the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where the LIDB data ultimately came from other than the LIDB AS for the calling number. >>>> >>>> Since the premise for this discussion is that calling names are not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their data be populated by untrustworthy sources. Is that correct? >>>> >>>> >>>> >>>> -hadriel >>>> >>>> _______________________________________________ >>>> 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 > > From br@brianrosen.net Tue Sep 3 13:04:39 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1413321E808C for ; Tue, 3 Sep 2013 13:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.978 X-Spam-Level: X-Spam-Status: No, score=-102.978 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHDg6Uqppa6U for ; Tue, 3 Sep 2013 13:04:34 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4516D21E804B for ; Tue, 3 Sep 2013 13:04:34 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 6so1800083qea.18 for ; Tue, 03 Sep 2013 13:04:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ahE1580MDVwp9E2bDcQruurnYVBMP4HCdmio8+5xyUM=; b=XKxmbiTf2fHc7m6bkpQPPd6TPDmj4mGJ8Rd1fWif/UVGEJNavy84vRuOx5VDdpvmqR Ou9d1bTp3Hs50MLV8y4OyIj0iQyq64g5weGJEyh9iqrYpRbwP+8/lD6EDGAzBMqfp1ZK 9GLdJ65h5zbdZ4RXwx0sv05gpQx7PasIs3105AJsAEJ/Oh2jyLOfGwfOZr3Moees1TIo MvNSBift6qwzxkbfrZjsbrN79YW4uCqKOaTJzkUCYZ1gjwEVQxGM+KTagEy/OD6g95ny xaVxAtGH6BB5niRVoxJsC3m0rYAZUbayAyTgMU8/tAkD95kapI8iA+PSB0jnN8w0ZRcQ CS5g== X-Gm-Message-State: ALoCoQlMD54zxp2SbPvTHzkh5TJ4jjeG/4kayiYW0ZwU/sm4x2DraL8bCOxuYTuSJh3Xj6HtmYiU X-Received: by 10.224.67.134 with SMTP id r6mr3016281qai.24.1378238666386; Tue, 03 Sep 2013 13:04:26 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id h2sm22115637qev.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 13:04:25 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <52263E86.3020403@alum.mit.edu> Date: Tue, 3 Sep 2013 16:04:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 20:04:39 -0000 So you want to cut the originating provider, who has the most = information available to validate the number, completely out of the = loop? We have this service now, and it's fairly good. Instead of paying the = origination provider for the LIDB dip, they pay us to dip out database = with the number. But because the only input to validation is phone = number, what comes out is variable quality. It also has a specific = problem that new service is very hard to accommodate. Until the number = is in use within the sources of data the database uses, the entry would = be considered unknown. That's not a huge problem to anyone but the new = customer. So the objection I have to termination side DB dip is that the quality = of validation is constrained by the limited amount of information in the = query. If I do validation on the origination, I get much better = results. That, by the way, is independent of any score that might be = sent in the signaling. =20 Brian On Sep 3, 2013, at 3:54 PM, Paul Kyzivat wrote: > On 9/3/13 3:36 PM, Brian Rosen wrote: >> Henning proposed to have some standardization of "method", but he = meant broad categories like "from billing records". That probably = doesn't help you, but I liked that idea. >>=20 >> Without the validation, how would we change anything? As it exists = now, both the display name, if sent, and the content of the CNAM = database can easily be anything you want if you use a pink carrier. How = would you propose to fix that? >=20 > As a user of this service, I would be more comfortable with it done by = an agent for the callee, based on number lookup. At least then the = callee has somebody to blame, and hopefully can choose which one. >=20 > At least this way the callee has a contract with *somebody* that will = say *something* about the level of trust in the data, and a recourse if = it turns out to be wrong. >=20 > I'm imagining that companies like Neustar would offer this service, = either directly to the end user, or to the provider for the callee. And = companies like Google might also provide a service like this. The = interface to the service need not be standardized. On smart phones you = could install a call validation app that plugs into incoming call = handling, and manages its own display of the information. >=20 > Thanks, > Paul >=20 >> Brian >>=20 >> On Sep 3, 2013, at 3:31 PM, Paul Kyzivat = wrote: >>=20 >>> Nits: >>>=20 >>> s/arose/arisen/ >>> s/scaler/scalar/ >>>=20 >>> Substance: >>>=20 >>> I'm still not buying the trust chain that says: >>>=20 >>> - caller supplies the name >>> - caller's provider provides the validation of the name, >>> using an undefined method and scale >>> - callee decides how to trust the name based on the >>> provided score and trust in the signer >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 9/3/13 1:32 PM, Brian Rosen wrote: >>>> I'm going to try and restate the "what is the problem", working off = what has been said. >>>>=20 >>>> In the PSTN today, there is an optional service that will display = the name of the caller. The name is currently obtained from a database. = Historically, the database is operated by the originating carrier, and = is populated with the name obtained from the billing and service data = used to establish the service. The database is queried by the = terminating carrier with the phone number to obtain the name. Recently, = due to charges levied on the terminating carrier by the originating = carrier to query the database, alternatives have arose where large = consumer oriented databases are queried that independently match name = with telephone number without reference to the originating carrier's = information. When the databases were operated by large established = telcos, the reliability of the data was good. However, some service = providers are now lax in how the data is populated, and some even = advertise the ability to allow any name to be used with a number. This = has significantly erod >>> ed >>>> the usefulness of the service. Where caller name service is = provided, it replaces the display of the calling party number, although = smart phones will usually substitute their local contact list name for = whatever is provided by the calling name service. This means that if = stir succeeds in improving the quality of the calling party number, but = no solution is provided for calling party name, fraudsters may still be = able to disguise their activities. >>>>=20 >>>> This work proposes to change how caller name is carried to using = the existing display name portion of the SIP URI in the =46rom or P-A-I = field. The name would be carried in the signaling from origination to = termination. This capability exists today, although the service = providers typically do not restrict or asses what name the caller = asserts. Therefore, along with the name would come a form of validation = that the name is genuine, and, for calls from businesses, the type of = business it is from. >>>>=20 >>>> Validation of names is exceedingly difficult, and this work does = not propose a solution that will provide a name with absolute certainty = that it is genuine and associated with the telephone number of the = calling party. It does propose that the data be vetted through some = process, which may not result in a simple "this is the name" result. = Rather, the vetting process may provide a name, but accompany it with a = confidence factor(score) indicating the source's assessment of the = likelihood that the name is represents the calling party. Confidence = would be a simple 0-100 scaler, without an attempt to precisely define = or normalize it between sources. That means that the termination side = would have to evaluate the confidence factor and the source of the = confidence together to decide how much to trust the name. The = termination could take a variety of actions based on the source and the = claimed confidence. Doing so implies that the number of sources is = limited so that evaluati >>> ng >>>> the source for trustworthiness can be accomplished. >>>>=20 >>>> Vetting the name at the source is more likely to be of value, = because the source may have a variety of other information about the = party the name is assigned to that can be used to improve the = reliability of the vetting process. For example, address, other phone = numbers, age, email addresses, domains (for businesses), etc can be used = to provide much higher confidence that the name accurately represents = the calling party than just the number known at the termination side. >>>>=20 >>>> Besides the name, when a call is made from a business, the type of = business can provide important information to the caller when deciding = to answer the call, or trust the caller. The type of business would be = a selection from an existing taxonomy of business types and would be = relatively high level ("bank", "florist", "doctor"). >>>>=20 >>>> The name, type of business (if appropriate), the source of the = data, the confidence indicator and some indication of the vetting = process would accompany the name in a new header in a secure manner -- = secure in the sense that the number, the name, type, the source, and the = sources' asserted confidence of the name is signed by the source. >>>>=20 >>>> If the termination side did not trust the source, or it did, but = the confidence was too low in its opinion, the termination may take a = number of actions, including, but not limited to: >>>> a) Refuse the call, or send it to voicemail >>>> b) Use an independent source of names, like the alternative name = suppliers that exist today to display an alternate name >>>> c) Provide a visual or audible warning to the user that the name = may not be valid >>>> d) Provide a visual or audible representation of the confidence, = possibly simplified (red/orange/yellow/green) >>>> e) Provide a caller feedback (thumbs up/down) mechanism to further = develop a rating of the source, or the specific name/number pair >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne = wrote: >>>>=20 >>>>> I didn't want to get into solution space, but I'm a bit surprised = by the question, since that's exactly what's been discussed, at length. = The idea was that, unlike today, the textual callerID is generally = traceable to the originating carrier and/or originating entity, for the = Organization/=46rom split I provided as an example earlier. >>>>>=20 >>>>> As pointed out, that's not always true today, given that the = destination has no clue which database is being used and who inserted = the information there - a tier-1 carrier based on business records, = listyourself.net based on caller assertion or some random white pages = service based on who-knows. >>>>>=20 >>>>> For the additional information, we have, as pointed out = repeatedly, numerous third-party databases, both private and = governmental. The originating carrier or possibly the originator can = obtain and sign that information as a value-add. The ARID approach is = another possibility. >>>>>=20 >>>>> I've tried to provide very specific examples of how this could = work, but am obviously not getting the point across. >>>>>=20 >>>>> ________________________________________ >>>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>>> Sent: Monday, September 02, 2013 11:51 AM >>>>> To: Henning Schulzrinne >>>>> Cc: Stephen Farrell; cnit@ietf.org >>>>> Subject: Re: [cnit] what's the actual problem here? >>>>>=20 >>>>>=20 >>>>>> (b) indicate provenance of the information (e.g., was this = inserted by the caller, the caller's carrier or by the receiving = carrier, CNAM-style) >>>>>=20 >>>>> I think that might be actually quite hard to accomplish, in a = trustworthy manner. The terminating carrier would know whether it got = the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it = doesn't know where the LIDB data ultimately came from other than the = LIDB AS for the calling number. >>>>>=20 >>>>> Since the premise for this discussion is that calling names are = not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting = their data be populated by untrustworthy sources. Is that correct? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -hadriel >>>>>=20 >>>>> _______________________________________________ >>>>> cnit mailing list >>>>> cnit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>=20 >>>> _______________________________________________ >>>> cnit mailing list >>>> cnit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cnit >>>>=20 >>>=20 >>> _______________________________________________ >>> cnit mailing list >>> cnit@ietf.org >>> https://www.ietf.org/mailman/listinfo/cnit >>=20 >>=20 >=20 From Henning.Schulzrinne@fcc.gov Tue Sep 3 13:29:57 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F6A21F9F3A for ; Tue, 3 Sep 2013 13:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0+mJ6RStf11 for ; Tue, 3 Sep 2013 13:29:54 -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 BA90421F9EF4 for ; Tue, 3 Sep 2013 13:29:53 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' , Paul Kyzivat Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgAGP9QCAAG6AkoABQEIAgAAhGoCAAAF1AIAABRgAgAACroD//8BXIA== Date: Tue, 3 Sep 2013 20:29:50 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 20:29:58 -0000 Particularly for individuals and small businesses, the information tying nu= mbers to names outside the carrier relationship can be of very low quality = and out-of-date, as numbers get re-assigned. If you look at the white pages= web pages, you may find who had the number a few years ago. Google doesn't= have magic information on who uses what phone number - most of those numbe= rs don't appear on web pages or other indexable information sources (and, i= f they did, you wouldn't want search engine optimization to kick in). For large businesses, you really want better information, namely the organi= zation name and possibly additional information such as the location ("Pizz= a Hut, Springfield") or caller name ("George Bailey, Bailey Savings & Loan"= ). Only the originator can provide this with any reliability, with the divi= sion of responsibility that I outlined earlier. The current system makes it difficult for legitimate entities to provide he= lpful information and easy for bad actors to provide misleading information= . Not a good combination. -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Tuesday, September 03, 2013 4:04 PM To: Paul Kyzivat Cc: cnit@ietf.org Subject: Re: [cnit] what's the actual problem here? So you want to cut the originating provider, who has the most information a= vailable to validate the number, completely out of the loop? We have this service now, and it's fairly good. Instead of paying the ori= gination provider for the LIDB dip, they pay us to dip out database with th= e number. But because the only input to validation is phone number, what c= omes out is variable quality. It also has a specific problem that new serv= ice is very hard to accommodate. Until the number is in use within the sou= rces of data the database uses, the entry would be considered unknown. Tha= t's not a huge problem to anyone but the new customer. So the objection I have to termination side DB dip is that the quality of v= alidation is constrained by the limited amount of information in the query.= If I do validation on the origination, I get much better results. That, = by the way, is independent of any score that might be sent in the signaling= . =20 Brian On Sep 3, 2013, at 3:54 PM, Paul Kyzivat wrote: > On 9/3/13 3:36 PM, Brian Rosen wrote: >> Henning proposed to have some standardization of "method", but he meant = broad categories like "from billing records". That probably doesn't help y= ou, but I liked that idea. >>=20 >> Without the validation, how would we change anything? As it exists now,= both the display name, if sent, and the content of the CNAM database can e= asily be anything you want if you use a pink carrier. How would you propos= e to fix that? >=20 > As a user of this service, I would be more comfortable with it done by an= agent for the callee, based on number lookup. At least then the callee has= somebody to blame, and hopefully can choose which one. >=20 > At least this way the callee has a contract with *somebody* that will say= *something* about the level of trust in the data, and a recourse if it tur= ns out to be wrong. >=20 > I'm imagining that companies like Neustar would offer this service, eithe= r directly to the end user, or to the provider for the callee. And companie= s like Google might also provide a service like this. The interface to the = service need not be standardized. On smart phones you could install a call = validation app that plugs into incoming call handling, and manages its own = display of the information. >=20 > Thanks, > Paul >=20 >> Brian >>=20 >> On Sep 3, 2013, at 3:31 PM, Paul Kyzivat wrote: >>=20 >>> Nits: >>>=20 >>> s/arose/arisen/ >>> s/scaler/scalar/ >>>=20 >>> Substance: >>>=20 >>> I'm still not buying the trust chain that says: >>>=20 >>> - caller supplies the name >>> - caller's provider provides the validation of the name, using an=20 >>> undefined method and scale >>> - callee decides how to trust the name based on the provided score=20 >>> and trust in the signer >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 9/3/13 1:32 PM, Brian Rosen wrote: >>>> I'm going to try and restate the "what is the problem", working off wh= at has been said. >>>>=20 >>>> In the PSTN today, there is an optional service that will display=20 >>>> the name of the caller. The name is currently obtained from a=20 >>>> database. Historically, the database is operated by the=20 >>>> originating carrier, and is populated with the name obtained from=20 >>>> the billing and service data used to establish the service. The=20 >>>> database is queried by the terminating carrier with the phone=20 >>>> number to obtain the name. Recently, due to charges levied on the=20 >>>> terminating carrier by the originating carrier to query the=20 >>>> database, alternatives have arose where large consumer oriented=20 >>>> databases are queried that independently match name with telephone=20 >>>> number without reference to the originating carrier's information. =20 >>>> When the databases were operated by large established telcos, the=20 >>>> reliability of the data was good. However, some service providers=20 >>>> are now lax in how the data is populated, and some even advertise=20 >>>> the ability to allow any name to be used with a number. This has=20 >>>> significantly e rod >>> ed >>>> the usefulness of the service. Where caller name service is provide= d, it replaces the display of the calling party number, although smart phon= es will usually substitute their local contact list name for whatever is pr= ovided by the calling name service. This means that if stir succeeds in im= proving the quality of the calling party number, but no solution is provide= d for calling party name, fraudsters may still be able to disguise their ac= tivities. >>>>=20 >>>> This work proposes to change how caller name is carried to using the e= xisting display name portion of the SIP URI in the From or P-A-I field. Th= e name would be carried in the signaling from origination to termination. = This capability exists today, although the service providers typically do n= ot restrict or asses what name the caller asserts. Therefore, along with t= he name would come a form of validation that the name is genuine, and, for = calls from businesses, the type of business it is from. >>>>=20 >>>> Validation of names is exceedingly difficult, and this work does=20 >>>> not propose a solution that will provide a name with absolute=20 >>>> certainty that it is genuine and associated with the telephone=20 >>>> number of the calling party. It does propose that the data be=20 >>>> vetted through some process, which may not result in a simple "this=20 >>>> is the name" result. Rather, the vetting process may provide a=20 >>>> name, but accompany it with a confidence factor(score) indicating=20 >>>> the source's assessment of the likelihood that the name is=20 >>>> represents the calling party. Confidence would be a simple 0-100=20 >>>> scaler, without an attempt to precisely define or normalize it=20 >>>> between sources. That means that the termination side would have=20 >>>> to evaluate the confidence factor and the source of the confidence=20 >>>> together to decide how much to trust the name. The termination=20 >>>> could take a variety of actions based on the source and the claimed=20 >>>> confidence. Doing so implies that the number of sources is limited=20 >>>> so that evalu ati >>> ng >>>> the source for trustworthiness can be accomplished. >>>>=20 >>>> Vetting the name at the source is more likely to be of value, because = the source may have a variety of other information about the party the name= is assigned to that can be used to improve the reliability of the vetting = process. For example, address, other phone numbers, age, email addresses, = domains (for businesses), etc can be used to provide much higher confidence= that the name accurately represents the calling party than just the number= known at the termination side. >>>>=20 >>>> Besides the name, when a call is made from a business, the type of bus= iness can provide important information to the caller when deciding to answ= er the call, or trust the caller. The type of business would be a selectio= n from an existing taxonomy of business types and would be relatively high = level ("bank", "florist", "doctor"). >>>>=20 >>>> The name, type of business (if appropriate), the source of the data, t= he confidence indicator and some indication of the vetting process would ac= company the name in a new header in a secure manner -- secure in the sense = that the number, the name, type, the source, and the sources' asserted conf= idence of the name is signed by the source. >>>>=20 >>>> If the termination side did not trust the source, or it did, but the c= onfidence was too low in its opinion, the termination may take a number of = actions, including, but not limited to: >>>> a) Refuse the call, or send it to voicemail >>>> b) Use an independent source of names, like the alternative name=20 >>>> suppliers that exist today to display an alternate name >>>> c) Provide a visual or audible warning to the user that the name=20 >>>> may not be valid >>>> d) Provide a visual or audible representation of the confidence,=20 >>>> possibly simplified (red/orange/yellow/green) >>>> e) Provide a caller feedback (thumbs up/down) mechanism to further=20 >>>> develop a rating of the source, or the specific name/number pair >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: >>>>=20 >>>>> I didn't want to get into solution space, but I'm a bit surprised by = the question, since that's exactly what's been discussed, at length. The id= ea was that, unlike today, the textual callerID is generally traceable to t= he originating carrier and/or originating entity, for the Organization/From= split I provided as an example earlier. >>>>>=20 >>>>> As pointed out, that's not always true today, given that the destinat= ion has no clue which database is being used and who inserted the informati= on there - a tier-1 carrier based on business records, listyourself.net bas= ed on caller assertion or some random white pages service based on who-know= s. >>>>>=20 >>>>> For the additional information, we have, as pointed out repeatedly, n= umerous third-party databases, both private and governmental. The originati= ng carrier or possibly the originator can obtain and sign that information = as a value-add. The ARID approach is another possibility. >>>>>=20 >>>>> I've tried to provide very specific examples of how this could work, = but am obviously not getting the point across. >>>>>=20 >>>>> ________________________________________ >>>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>>> Sent: Monday, September 02, 2013 11:51 AM >>>>> To: Henning Schulzrinne >>>>> Cc: Stephen Farrell; cnit@ietf.org >>>>> Subject: Re: [cnit] what's the actual problem here? >>>>>=20 >>>>>=20 >>>>>> (b) indicate provenance of the information (e.g., was this=20 >>>>>> inserted by the caller, the caller's carrier or by the receiving=20 >>>>>> carrier, CNAM-style) >>>>>=20 >>>>> I think that might be actually quite hard to accomplish, in a trustwo= rthy manner. The terminating carrier would know whether it got the name fr= om a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know wher= e the LIDB data ultimately came from other than the LIDB AS for the calling= number. >>>>>=20 >>>>> Since the premise for this discussion is that calling names are not t= rustworthy anymore (?), I'm assuming the LIDB AS'es are letting their data = be populated by untrustworthy sources. Is that correct? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -hadriel >>>>>=20 >>>>> _______________________________________________ >>>>> cnit mailing list >>>>> cnit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>=20 >>>> _______________________________________________ >>>> cnit mailing list >>>> cnit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cnit >>>>=20 >>>=20 >>> _______________________________________________ >>> cnit mailing list >>> cnit@ietf.org >>> https://www.ietf.org/mailman/listinfo/cnit >>=20 >>=20 >=20 _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From pogran@alum.mit.edu Tue Sep 3 13:43:14 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D95021E8064 for ; Tue, 3 Sep 2013 13:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7MCR2qVs8J7 for ; Tue, 3 Sep 2013 13:43:08 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by ietfa.amsl.com (Postfix) with ESMTP id 34F9C21E8083 for ; Tue, 3 Sep 2013 13:43:08 -0700 (PDT) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=RvL8ckWK c=1 sm=0 tr=0 a=zyEqb+KCu+mIaNqjm1WFWQ==:117 a=zyEqb+KCu+mIaNqjm1WFWQ==:17 a=K-v-2zaBAAAA:8 a=H60vlihRZSsA:10 a=vc5lCoSdESQA:10 a=kj9zAlcOel0A:10 a=WRdS7oYUjucA:10 a=dpgSGuiDVefymhTNt6wA:9 a=qBFHOlVkUOEhqNtu:21 a=-4mvLJeA7awWLTaO:21 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=pogran@alum.mit.edu; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=pogran@alum.mit.edu; spf=softfail; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=pogran; auth=pass (LOGIN) Received-SPF: softfail (smtp01.rcn.cmh.synacor.com: transitional domain alum.mit.edu does not designate 72.93.100.146 as permitted sender) Received: from [72.93.100.146] ([72.93.100.146:58255] helo=[198.179.132.36]) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTPA id 4F/70-07508-9D946225; Tue, 03 Sep 2013 16:43:07 -0400 User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Tue, 03 Sep 2013 16:43:03 -0400 From: Ken Pogran To: Paul Kyzivat , Message-ID: Thread-Topic: [cnit] what's the actual problem here? In-Reply-To: <52263907.4050602@alum.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 20:43:14 -0000 On 9/3/13 3:31 PM, "Paul Kyzivat" wrote: >I'm still not buying the trust chain that says: > >- caller supplies the name >- caller's provider provides the validation of the name, > using an undefined method and scale >- callee decides how to trust the name based on the > provided score and trust in the signer With regard to the first step in the chain, I believe one of the key points is WHEN does the caller supply the name? With PSTN LIDB that happens at service subscription time (when the caller first establishes his/her telephone service) and IMO that is a model that imparts greater trust. The next step, "caller's provider provides the validation of the name..." effectively occurs when the provider provisions the telephone number record with the validated name into LIDB. The call-terminating provider, as "callee's agent", dips the LIDB designated by the caller's provider (as published in the Calling Name Routing Guide) and presents the resulting CNAM string to the callee. Or, the call-terminating provider dips an alternative CNAM database and presents that result. In the case of LIDB we know the caller's provider has validated the caller's name as part of service establishment. In the case of non-LIDB CNAM databases it is important to understand how and from where the caller name data is constructed. In that vein, I would tend to trust Neustar's database more than I would Joe's Cheapo CNAM Service. Ken Pogran From stephen.farrell@cs.tcd.ie Tue Sep 3 16:06:34 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7539821F90CF for ; Tue, 3 Sep 2013 16:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr1v3LA9iLAa for ; Tue, 3 Sep 2013 16:06:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 86A8821F999D for ; Tue, 3 Sep 2013 16:06:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9CF2EBE5D; Wed, 4 Sep 2013 00:06:18 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30Af1PS3iDe0; Wed, 4 Sep 2013 00:06:18 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.53.104]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A7A71BE5B; Wed, 4 Sep 2013 00:06:15 +0100 (IST) Message-ID: <52266B5B.5060703@cs.tcd.ie> Date: Wed, 04 Sep 2013 00:06:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "cnit@ietf.org" , Paul Kyzivat , 'Brian Rosen' Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 23:06:34 -0000 On 09/03/2013 09:29 PM, Henning Schulzrinne wrote: > The current system makes it difficult for legitimate entities to > provide helpful information and easy for bad actors to provide > misleading information. Not a good combination. True, that's not a good combination. But, OTOH, just not defining such a service would also nicely solve that problem. FWIW, that (not bothering) seems more attractive to me personally when I consider the privacy issues that might arise were we to standardise this service. Especially given that callee address books and enterprise directories seem to work just fine, and since the other use cases that I've heard so far don't seem the least bit compelling (those being: "I want to charge US$") given the privacy and complexity downsides. And before someone asks, STIR is different since its dealing with phone numbers which are required for making at least some calls. In contrast names as discussed here are not required at all. So all in all, I'm not seeing why we should bother doing any work here. But I could well be wrong, that happens all the time:-) S. From pkyzivat@alum.mit.edu Tue Sep 3 19:11:15 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F319021E8129 for ; Tue, 3 Sep 2013 19:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.342 X-Spam-Level: X-Spam-Status: No, score=-0.342 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L46SVu2vMtP1 for ; Tue, 3 Sep 2013 19:11:09 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 0D37221E8139 for ; Tue, 3 Sep 2013 19:11:07 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id Lmzq1m00E0SCNGk56qAzwD; Wed, 04 Sep 2013 02:10:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id LqAy1m0123ZTu2S3VqAzAF; Wed, 04 Sep 2013 02:10:59 +0000 Message-ID: <522696B2.2030708@alum.mit.edu> Date: Tue, 03 Sep 2013 22:10:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52266B5B.5060703@cs.tcd.ie> In-Reply-To: <52266B5B.5060703@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378260659; bh=FyVgSlSFGVUbTaXXrTniBCsvA9aypqfBLg++XhFSfAk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BL1lSdeHJvUrF7zxtJ/fiXFaczVQAZk+5FZ1pApt2EW//HhmflzBfsKLJFPAiBkwf mPqw7K4ySz7dW3oudGCEKgM8AFvWN1sPbfl5HPPE5C9shIA99wgOPXTeGgjlga2q5p Ban4wKbmGUd6TBdM4ThDw6NFEfWY/ICvkPyKVG6RVXVG/j4j66PIKodJMh0bUKpRpo yZqgxdK3jQg+1wDLVzU5UxJeBQUY80xuJfzn+Ni0nCN2f9heyK6BXXNAJAC8FhFAHW 78DtU1a++lMWKMalNDFH8KCLq+iGAKor4TPqRho8yh0/xI8kO/3aBqhzCSjc/nyd8V WGRlYSYBD2XSg== Cc: "cnit@ietf.org" , 'Brian Rosen' , Henning Schulzrinne Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 02:11:15 -0000 Stephen, Its easy for somebody from a place that doesn't have it to suggest this. But in the US the expectation has been set. This feature, when it works as intended, *is* useful. I get reminder calls from doctors, pharmacies, and sometimes from banks. Often these aren't from numbers that I know. It is indeed useful information to decide whether to answer. (And for a shared home phone, to decide *who* should answer.) Thanks, Paul On 9/3/13 7:06 PM, Stephen Farrell wrote: > > > On 09/03/2013 09:29 PM, Henning Schulzrinne wrote: >> The current system makes it difficult for legitimate entities to >> provide helpful information and easy for bad actors to provide >> misleading information. Not a good combination. > > True, that's not a good combination. > > But, OTOH, just not defining such a service would also > nicely solve that problem. > > FWIW, that (not bothering) seems more attractive to > me personally when I consider the privacy issues that > might arise were we to standardise this service. > Especially given that callee address books and enterprise > directories seem to work just fine, and since the > other use cases that I've heard so far don't seem > the least bit compelling (those being: "I want to > charge US$") given the privacy and complexity downsides. > > And before someone asks, STIR is different since its > dealing with phone numbers which are required for > making at least some calls. In contrast names as > discussed here are not required at all. > > So all in all, I'm not seeing why we should bother > doing any work here. But I could well be wrong, that > happens all the time:-) > > S. > From sanjay.mishra@verizon.com Tue Sep 3 19:42:59 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9346821E80F2 for ; Tue, 3 Sep 2013 19:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.863 X-Spam-Level: X-Spam-Status: No, score=-3.863 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzg5qjUTBFr9 for ; Tue, 3 Sep 2013 19:42:54 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 122A821E8094 for ; Tue, 3 Sep 2013 19:42:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe03.verizonbusiness.com with ESMTP; 04 Sep 2013 02:42:51 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.89,1017,1367971200"; d="scan'208";a="540554408" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 04 Sep 2013 02:42:51 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Tue, 3 Sep 2013 22:42:51 -0400 To: Paul Kyzivat , Stephen Farrell Date: Tue, 3 Sep 2013 22:42:49 -0400 Thread-Topic: [cnit] what's the actual problem here? Thread-Index: Ac6pFBJpsfhozxlTRSqgYPOg7ahg/gAA/ltA Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C79791F9E@FHDP1LUMXC7V23.us.one.verizon.com> References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52266B5B.5060703@cs.tcd.ie> <522696B2.2030708@alum.mit.edu> In-Reply-To: <522696B2.2030708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , Henning Schulzrinne , 'Brian Rosen' Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 02:42:59 -0000 +1. Our household only answers phone from names that are recognized on the call= er ID otherwise the phone goes to the VM. Thanks Sanjay -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Tuesday, September 03, 2013 10:11 PM To: Stephen Farrell Cc: cnit@ietf.org; 'Brian Rosen'; Henning Schulzrinne Subject: Re: [cnit] what's the actual problem here? Stephen, Its easy for somebody from a place that doesn't have it to suggest this.=20 But in the US the expectation has been set. This feature, when it works as intended, *is* useful. I get reminder calls = from doctors, pharmacies, and sometimes from banks. Often these aren't from= numbers that I know. It is indeed useful information to decide whether to = answer. (And for a shared home phone, to decide *who* should answer.) Thanks, Paul On 9/3/13 7:06 PM, Stephen Farrell wrote: > > > On 09/03/2013 09:29 PM, Henning Schulzrinne wrote: >> The current system makes it difficult for legitimate entities to=20 >> provide helpful information and easy for bad actors to provide=20 >> misleading information. Not a good combination. > > True, that's not a good combination. > > But, OTOH, just not defining such a service would also nicely solve=20 > that problem. > > FWIW, that (not bothering) seems more attractive to me personally when=20 > I consider the privacy issues that might arise were we to standardise=20 > this service. > Especially given that callee address books and enterprise directories=20 > seem to work just fine, and since the other use cases that I've heard=20 > so far don't seem the least bit compelling (those being: "I want to=20 > charge US$") given the privacy and complexity downsides. > > And before someone asks, STIR is different since its dealing with=20 > phone numbers which are required for making at least some calls. In=20 > contrast names as discussed here are not required at all. > > So all in all, I'm not seeing why we should bother doing any work=20 > here. But I could well be wrong, that happens all the time:-) > > S. > _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From Henning.Schulzrinne@fcc.gov Tue Sep 3 20:24:24 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD4F11E80D1 for ; Tue, 3 Sep 2013 20:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, GB_PHARMACY=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tARsHA4vf8c9 for ; Tue, 3 Sep 2013 20:24:20 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36021F99A4 for ; Tue, 3 Sep 2013 20:24:19 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Mishra, Sanjay" , Paul Kyzivat , Stephen Farrell Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgAGP9QCAAG6AkoABQEIAgAAhGoCAAAF1AIAABRgAgAACroD//8BXIIAAcm2AgAAzqgCAAAjmgP//xqoL Date: Wed, 4 Sep 2013 03:24:16 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52266B5B.5060703@cs.tcd.ie> <522696B2.2030708@alum.mit.edu>, <900A1E2059ADB149B905E3C8FA0046A62C79791F9E@FHDP1LUMXC7V23.us.one.verizon.com> In-Reply-To: <900A1E2059ADB149B905E3C8FA0046A62C79791F9E@FHDP1LUMXC7V23.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 03:24:24 -0000 And on our fairly-new cordless (DECT) phone, there's a text-to-speech featu= re that announces "Call from Rite Aid Pharmacy". (It's actually surprisingl= y clever about pronouncing names.) Much more user friendly than "Call from = two one two five five five one two one two". For a variety of user interfac= e reasons, such phones typically don't have extensive address books, and, a= s mentioned, if they do, they don't typically contain business numbers.=0A= =0A= Steve, you might want to suggest such a feature to your local phone company= instead of taking it away from US consumers...=0A= =0A= ________________________________________=0A= From: Mishra, Sanjay [sanjay.mishra@verizon.com]=0A= Sent: Tuesday, September 03, 2013 10:42 PM=0A= To: Paul Kyzivat; Stephen Farrell=0A= Cc: cnit@ietf.org; 'Brian Rosen'; Henning Schulzrinne=0A= Subject: RE: [cnit] what's the actual problem here?=0A= =0A= +1.=0A= =0A= Our household only answers phone from names that are recognized on the call= er ID otherwise the phone goes to the VM.=0A= =0A= Thanks=0A= Sanjay=0A= =0A= -----Original Message-----=0A= From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Pau= l Kyzivat=0A= Sent: Tuesday, September 03, 2013 10:11 PM=0A= To: Stephen Farrell=0A= Cc: cnit@ietf.org; 'Brian Rosen'; Henning Schulzrinne=0A= Subject: Re: [cnit] what's the actual problem here?=0A= =0A= Stephen,=0A= =0A= Its easy for somebody from a place that doesn't have it to suggest this.=0A= But in the US the expectation has been set.=0A= =0A= This feature, when it works as intended, *is* useful. I get reminder calls = from doctors, pharmacies, and sometimes from banks. Often these aren't from= numbers that I know. It is indeed useful information to decide whether to = answer. (And for a shared home phone, to decide *who* should answer.)=0A= =0A= Thanks,=0A= Paul=0A= =0A= On 9/3/13 7:06 PM, Stephen Farrell wrote:=0A= >=0A= >=0A= > On 09/03/2013 09:29 PM, Henning Schulzrinne wrote:=0A= >> The current system makes it difficult for legitimate entities to=0A= >> provide helpful information and easy for bad actors to provide=0A= >> misleading information. Not a good combination.=0A= >=0A= > True, that's not a good combination.=0A= >=0A= > But, OTOH, just not defining such a service would also nicely solve=0A= > that problem.=0A= >=0A= > FWIW, that (not bothering) seems more attractive to me personally when=0A= > I consider the privacy issues that might arise were we to standardise=0A= > this service.=0A= > Especially given that callee address books and enterprise directories=0A= > seem to work just fine, and since the other use cases that I've heard=0A= > so far don't seem the least bit compelling (those being: "I want to=0A= > charge US$") given the privacy and complexity downsides.=0A= >=0A= > And before someone asks, STIR is different since its dealing with=0A= > phone numbers which are required for making at least some calls. In=0A= > contrast names as discussed here are not required at all.=0A= >=0A= > So all in all, I'm not seeing why we should bother doing any work=0A= > here. But I could well be wrong, that happens all the time:-)=0A= >=0A= > S.=0A= >=0A= =0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= From hadriel.kaplan@oracle.com Wed Sep 4 09:04:39 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF3D11E81B3 for ; Wed, 4 Sep 2013 09:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMJOgIQ+d8Ak for ; Wed, 4 Sep 2013 09:04:34 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE6721F8C20 for ; Wed, 4 Sep 2013 09:04:33 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r84G4QSP004297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Sep 2013 16:04:27 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r84G4NF3003005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 16:04:24 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r84G4Mei013414; Wed, 4 Sep 2013 16:04:23 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Sep 2013 09:04:22 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 4 Sep 2013 12:04:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 16:04:39 -0000 I asked the question because it seems to me there's a contradiction in = here somewhere. =46rom a 10k foot view, the current LIDB model is essentially the model = being proposed as the solution. Not the pricing model, maybe, but the = architectural model. The model being proposed is "the originator uses a name validation = service that provides some assertion about the originating text name, = and everyone else trusts that validation service's assertion". That = sure sounds like LIDB to me, just with different powerpoint slide icons. = The LIDB AS runs the database for its phone number customers, and in = theory the AS should audit/verify the contents of its name entries to be = valid. It also provides a lot more than simply calling name data today, = and if we think it needs even more information then we can talk about = that. But if bad names are entering the LIDB databases, then I don't know why = we think they won't enter whatever "validation service" we're talking = about. Sure they might not enter TARGUSinfo databases, but there's no = reason to think everyone will start using TARGUSinfo for their = validation service. For example why wouldn't the existing LIDB AS = providers simply market themselves as a "validation service" to their = existing customers? And since some Tier-1 carriers run their own LIDB = AS, why would they switch to someone else? If the answer to that is "well no one would trust claimed names from = LIDB AS", I find that hard to believe, since they appear to be trusted = sufficiently right now; and it's not in the power of the terminating = carriers to force the originating carriers to use a different LIDB AS. Ultimately if this whole thing just boils down to "we don't know how = this name got into the DB", then add a field to LIDB identifying the = source... if an existing field doesn't already do that. (what does the = "Account Owner" field hold?) The other "problem" I've heard about LIDB is the pricing model, but = that's a separate issue. -hadriel On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne = wrote: > I didn't want to get into solution space, but I'm a bit surprised by = the question, since that's exactly what's been discussed, at length. The = idea was that, unlike today, the textual callerID is generally traceable = to the originating carrier and/or originating entity, for the = Organization/=46rom split I provided as an example earlier. >=20 > As pointed out, that's not always true today, given that the = destination has no clue which database is being used and who inserted = the information there - a tier-1 carrier based on business records, = listyourself.net based on caller assertion or some random white pages = service based on who-knows. >=20 > For the additional information, we have, as pointed out repeatedly, = numerous third-party databases, both private and governmental. The = originating carrier or possibly the originator can obtain and sign that = information as a value-add. The ARID approach is another possibility. >=20 > I've tried to provide very specific examples of how this could work, = but am obviously not getting the point across. >=20 > ________________________________________ > From: Hadriel Kaplan [hadriel.kaplan@oracle.com] > Sent: Monday, September 02, 2013 11:51 AM > To: Henning Schulzrinne > Cc: Stephen Farrell; cnit@ietf.org > Subject: Re: [cnit] what's the actual problem here? >=20 >=20 >> (b) indicate provenance of the information (e.g., was this inserted = by the caller, the caller's carrier or by the receiving carrier, = CNAM-style) >=20 > I think that might be actually quite hard to accomplish, in a = trustworthy manner. The terminating carrier would know whether it got = the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it = doesn't know where the LIDB data ultimately came from other than the = LIDB AS for the calling number. >=20 > Since the premise for this discussion is that calling names are not = trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their = data be populated by untrustworthy sources. Is that correct? >=20 >=20 >=20 > -hadriel >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From Henning.Schulzrinne@fcc.gov Wed Sep 4 09:22:47 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2910B21F991F for ; Wed, 4 Sep 2013 09:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqkorpYCyy4a for ; Wed, 4 Sep 2013 09:22:39 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id E42C821F8934 for ; Wed, 4 Sep 2013 09:22:32 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgAGP9QCAAG6AkoACud8A//++a0A= Date: Wed, 4 Sep 2013 16:14:58 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 16:22:47 -0000 I think it helps if we distinguish between two models, the "basic" (name + = organization) in-band delivery, and extended information (location, busines= s type). The latter is by reference, due to size and maybe other practical= issues, and doesn't really exist today. For tier-1 providers, the basic process may not change all that much, excep= t that the information will be carried in-band for end-to-end VoIP calls, r= ather than (just) be inserted into a database and will have provenance info= rmation to distinguish it reliably from information derived from other, mor= e indirect, sources. I don't see this as a major undertaking or fundamental change - a large fra= ction of the current textual callerID is valid, but even if 95% is, it's im= possible for the end user to tell which 95%, and the bad 5% can really ruin= your day (and bank account). -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Wednesday, September 04, 2013 12:04 PM To: Henning Schulzrinne Cc: cnit@ietf.org; Stephen Farrell Subject: Re: [cnit] what's the actual problem here? I asked the question because it seems to me there's a contradiction in here= somewhere. >From a 10k foot view, the current LIDB model is essentially the model being= proposed as the solution. Not the pricing model, maybe, but the architect= ural model. The model being proposed is "the originator uses a name validation service = that provides some assertion about the originating text name, and everyone = else trusts that validation service's assertion". That sure sounds like LI= DB to me, just with different powerpoint slide icons. The LIDB AS runs the= database for its phone number customers, and in theory the AS should audit= /verify the contents of its name entries to be valid. It also provides a l= ot more than simply calling name data today, and if we think it needs even = more information then we can talk about that. But if bad names are entering the LIDB databases, then I don't know why we = think they won't enter whatever "validation service" we're talking about. = Sure they might not enter TARGUSinfo databases, but there's no reason to th= ink everyone will start using TARGUSinfo for their validation service. For= example why wouldn't the existing LIDB AS providers simply market themselv= es as a "validation service" to their existing customers? And since some T= ier-1 carriers run their own LIDB AS, why would they switch to someone else= ? If the answer to that is "well no one would trust claimed names from LIDB A= S", I find that hard to believe, since they appear to be trusted sufficient= ly right now; and it's not in the power of the terminating carriers to forc= e the originating carriers to use a different LIDB AS. Ultimately if this whole thing just boils down to "we don't know how this n= ame got into the DB", then add a field to LIDB identifying the source... if= an existing field doesn't already do that. (what does the "Account Owner" = field hold?) The other "problem" I've heard about LIDB is the pricing model, but that's = a separate issue. -hadriel On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: > I didn't want to get into solution space, but I'm a bit surprised by the = question, since that's exactly what's been discussed, at length. The idea w= as that, unlike today, the textual callerID is generally traceable to the o= riginating carrier and/or originating entity, for the Organization/From spl= it I provided as an example earlier. >=20 > As pointed out, that's not always true today, given that the destination = has no clue which database is being used and who inserted the information t= here - a tier-1 carrier based on business records, listyourself.net based o= n caller assertion or some random white pages service based on who-knows. >=20 > For the additional information, we have, as pointed out repeatedly, numer= ous third-party databases, both private and governmental. The originating c= arrier or possibly the originator can obtain and sign that information as a= value-add. The ARID approach is another possibility. >=20 > I've tried to provide very specific examples of how this could work, but = am obviously not getting the point across. >=20 > ________________________________________ > From: Hadriel Kaplan [hadriel.kaplan@oracle.com] > Sent: Monday, September 02, 2013 11:51 AM > To: Henning Schulzrinne > Cc: Stephen Farrell; cnit@ietf.org > Subject: Re: [cnit] what's the actual problem here? >=20 >=20 >> (b) indicate provenance of the information (e.g., was this inserted by t= he caller, the caller's carrier or by the receiving carrier, CNAM-style) >=20 > I think that might be actually quite hard to accomplish, in a trustworthy= manner. The terminating carrier would know whether it got the name from a= LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where th= e LIDB data ultimately came from other than the LIDB AS for the calling num= ber. >=20 > Since the premise for this discussion is that calling names are not trust= worthy anymore (?), I'm assuming the LIDB AS'es are letting their data be p= opulated by untrustworthy sources. Is that correct? >=20 >=20 >=20 > -hadriel >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From br@brianrosen.net Wed Sep 4 10:19:24 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C8E11E81C3 for ; Wed, 4 Sep 2013 10:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.978 X-Spam-Level: X-Spam-Status: No, score=-102.978 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEsibMC01yFw for ; Wed, 4 Sep 2013 10:19:20 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id BC25111E80F5 for ; Wed, 4 Sep 2013 10:19:19 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id hu16so2162815qab.14 for ; Wed, 04 Sep 2013 10:19:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=tOxqZ/yfhrSIoQ6oqFIB65qH2ZwQcenNi5DWtdEifMg=; b=XO226jtT0+eHj2ONTbHJ9xO21skT6gCA8awS37DK2TEf/BXCiYROAiW1k1e/kWpSZQ 1XmFpe7OrNE+igB9svAIGJ+hVqXnOHGrm1u0Yb4J2Z4T7SBgEy61id7ancUg0fd2sonl pu9AIYawGhnQq89sU/lLAZoMe6dB+CKBpuF37TU9xtl6uImsbGVFP+ZM4fK2hR11Tdqg nWbxi4+2AZ3gBcL0DFY5FjFVPNwK9nmeHTNQ79czSZwC6JC9fpfLDKiWiiC3xbz2ffGa WgXPDTyN61hZQ2YXpEEIwx+Pz5EtGvCUQqmTFqSkX3CiZMoDocPRERy5YngT56iro9iQ aPqg== X-Gm-Message-State: ALoCoQnHV5NFsKB1Nq+iSMHgURAHQ9IjvFG1Bex58ULW20UcI7yjyJgXL/OoO9gwvrKjV9/URGmv X-Received: by 10.49.49.74 with SMTP id s10mr4178289qen.29.1378315155420; Wed, 04 Sep 2013 10:19:15 -0700 (PDT) Received: from [10.33.203.84] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id i10sm38691534qev.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 10:19:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: Date: Wed, 4 Sep 2013 13:19:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <65358661-ED23-4D4F-9293-624EA007EE91@brianrosen.net> References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Stephen Farrell , Henning Schulzrinne Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 17:19:24 -0000 The architectural difference is that the data is carried in the = signaling, not queried by the termination side. Today, each provider loads the data with whatever it wants in the way of = validation. We propose to carry the identity of the validation, and the = type of validation provided, in the signaling, in the hope that = providers will use a relatively small number of 3rd party validation = services instead of, or in addition to, any validation they do now. =20 Peering arrangements could cover this kind of thing to. A "green" = provider could have a requirement that calls coming into its network = have a name validated by an acceptable (to it) validation source. =20 A termination network might suppress names that weren't from a source it = trusted. Brian On Sep 4, 2013, at 12:04 PM, Hadriel Kaplan = wrote: >=20 > I asked the question because it seems to me there's a contradiction in = here somewhere. >=20 > =46rom a 10k foot view, the current LIDB model is essentially the = model being proposed as the solution. Not the pricing model, maybe, but = the architectural model. >=20 > The model being proposed is "the originator uses a name validation = service that provides some assertion about the originating text name, = and everyone else trusts that validation service's assertion". That = sure sounds like LIDB to me, just with different powerpoint slide icons. = The LIDB AS runs the database for its phone number customers, and in = theory the AS should audit/verify the contents of its name entries to be = valid. It also provides a lot more than simply calling name data today, = and if we think it needs even more information then we can talk about = that. >=20 > But if bad names are entering the LIDB databases, then I don't know = why we think they won't enter whatever "validation service" we're = talking about. Sure they might not enter TARGUSinfo databases, but = there's no reason to think everyone will start using TARGUSinfo for = their validation service. For example why wouldn't the existing LIDB AS = providers simply market themselves as a "validation service" to their = existing customers? And since some Tier-1 carriers run their own LIDB = AS, why would they switch to someone else? >=20 > If the answer to that is "well no one would trust claimed names from = LIDB AS", I find that hard to believe, since they appear to be trusted = sufficiently right now; and it's not in the power of the terminating = carriers to force the originating carriers to use a different LIDB AS. >=20 > Ultimately if this whole thing just boils down to "we don't know how = this name got into the DB", then add a field to LIDB identifying the = source... if an existing field doesn't already do that. (what does the = "Account Owner" field hold?) >=20 > The other "problem" I've heard about LIDB is the pricing model, but = that's a separate issue. >=20 > -hadriel >=20 >=20 > On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne = wrote: >=20 >> I didn't want to get into solution space, but I'm a bit surprised by = the question, since that's exactly what's been discussed, at length. The = idea was that, unlike today, the textual callerID is generally traceable = to the originating carrier and/or originating entity, for the = Organization/=46rom split I provided as an example earlier. >>=20 >> As pointed out, that's not always true today, given that the = destination has no clue which database is being used and who inserted = the information there - a tier-1 carrier based on business records, = listyourself.net based on caller assertion or some random white pages = service based on who-knows. >>=20 >> For the additional information, we have, as pointed out repeatedly, = numerous third-party databases, both private and governmental. The = originating carrier or possibly the originator can obtain and sign that = information as a value-add. The ARID approach is another possibility. >>=20 >> I've tried to provide very specific examples of how this could work, = but am obviously not getting the point across. >>=20 >> ________________________________________ >> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >> Sent: Monday, September 02, 2013 11:51 AM >> To: Henning Schulzrinne >> Cc: Stephen Farrell; cnit@ietf.org >> Subject: Re: [cnit] what's the actual problem here? >>=20 >>=20 >>> (b) indicate provenance of the information (e.g., was this inserted = by the caller, the caller's carrier or by the receiving carrier, = CNAM-style) >>=20 >> I think that might be actually quite hard to accomplish, in a = trustworthy manner. The terminating carrier would know whether it got = the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it = doesn't know where the LIDB data ultimately came from other than the = LIDB AS for the calling number. >>=20 >> Since the premise for this discussion is that calling names are not = trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their = data be populated by untrustworthy sources. Is that correct? >>=20 >>=20 >>=20 >> -hadriel >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From pkyzivat@alum.mit.edu Wed Sep 4 12:50:05 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA7811E8109 for ; Wed, 4 Sep 2013 12:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0oyNddoP+Xi for ; Wed, 4 Sep 2013 12:50:01 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id E570B11E8116 for ; Wed, 4 Sep 2013 12:50:00 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id Lzrt1m0081ap0As557q0YV; Wed, 04 Sep 2013 19:50:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id M7pz1m0143ZTu2S3i7pz4y; Wed, 04 Sep 2013 19:50:00 +0000 Message-ID: <52278EE6.1090400@alum.mit.edu> Date: Wed, 04 Sep 2013 15:49:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378324200; bh=+XXHlEpoT84mRCMxfOkJ2bKc9OSWGZ5OvUhN1K/1UPw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IL/JUuw7/9B4qjCNTSRcRGqYVymaAiIMyEmjNMhJnGw8oh+h7dYZAJDy0bvoGxAXB pe/Jp0o4vgd77b4rFxAbo7+cU/Yu5hA6QJGvQSVqUMhA5SM6WkoK7onRmy2K5g1GrM fXvXPRngIPL4KucGFY9p5waw8WW15mH2F2p+HsRzaYEil1xQ9OHceTOvTYuMOVXl/+ jiMCKV/9EcPoSO6FtBgkUgZb+jfle2orCUneY1pzd7GVZCRHNsjfRg7ob/Gc0pbEti caasZqBdu6nZqtsML0UtSzmRzme+ipRbqeUj059Mf36bml5dB3Z9r/0bax+PiZ4ob1 5F5+2s/jD/5Hg== Cc: cnit@ietf.org Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:50:05 -0000 Brian, My issue is with the trust model. Today this is a service offered by my provider. If there are problems, I would complain to my provider. It may be that my provider gets the data from a DB that was populated by the calling provider, but that is not *my* problem. IIUC, in what you are proposing, the data I get will be signed by the caller or calling provider. Then I must decide whether to trust that. And if there are problems, then I presumably need to take it up with that provider. Thanks, Paul On 9/3/13 4:04 PM, Brian Rosen wrote: > So you want to cut the originating provider, who has the most information available to validate the number, completely out of the loop? > > We have this service now, and it's fairly good. Instead of paying the origination provider for the LIDB dip, they pay us to dip out database with the number. But because the only input to validation is phone number, what comes out is variable quality. It also has a specific problem that new service is very hard to accommodate. Until the number is in use within the sources of data the database uses, the entry would be considered unknown. That's not a huge problem to anyone but the new customer. > > So the objection I have to termination side DB dip is that the quality of validation is constrained by the limited amount of information in the query. If I do validation on the origination, I get much better results. That, by the way, is independent of any score that might be sent in the signaling. > > Brian > > > On Sep 3, 2013, at 3:54 PM, Paul Kyzivat wrote: > >> On 9/3/13 3:36 PM, Brian Rosen wrote: >>> Henning proposed to have some standardization of "method", but he meant broad categories like "from billing records". That probably doesn't help you, but I liked that idea. >>> >>> Without the validation, how would we change anything? As it exists now, both the display name, if sent, and the content of the CNAM database can easily be anything you want if you use a pink carrier. How would you propose to fix that? >> >> As a user of this service, I would be more comfortable with it done by an agent for the callee, based on number lookup. At least then the callee has somebody to blame, and hopefully can choose which one. >> >> At least this way the callee has a contract with *somebody* that will say *something* about the level of trust in the data, and a recourse if it turns out to be wrong. >> >> I'm imagining that companies like Neustar would offer this service, either directly to the end user, or to the provider for the callee. And companies like Google might also provide a service like this. The interface to the service need not be standardized. On smart phones you could install a call validation app that plugs into incoming call handling, and manages its own display of the information. >> >> Thanks, >> Paul >> >>> Brian >>> >>> On Sep 3, 2013, at 3:31 PM, Paul Kyzivat wrote: >>> >>>> Nits: >>>> >>>> s/arose/arisen/ >>>> s/scaler/scalar/ >>>> >>>> Substance: >>>> >>>> I'm still not buying the trust chain that says: >>>> >>>> - caller supplies the name >>>> - caller's provider provides the validation of the name, >>>> using an undefined method and scale >>>> - callee decides how to trust the name based on the >>>> provided score and trust in the signer >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 9/3/13 1:32 PM, Brian Rosen wrote: >>>>> I'm going to try and restate the "what is the problem", working off what has been said. >>>>> >>>>> In the PSTN today, there is an optional service that will display the name of the caller. The name is currently obtained from a database. Historically, the database is operated by the originating carrier, and is populated with the name obtained from the billing and service data used to establish the service. The database is queried by the terminating carrier with the phone number to obtain the name. Recently, due to charges levied on the terminating carrier by the originating carrier to query the database, alternatives have arose where large consumer oriented databases are queried that independently match name with telephone number without reference to the originating carrier's information. When the databases were operated by large established telcos, the reliability of the data was good. However, some service providers are now lax in how the data is populated, and some even advertise the ability to allow any name to be used with a number. This has significantly erod >>>> ed >>>>> the usefulness of the service. Where caller name service is provided, it replaces the display of the calling party number, although smart phones will usually substitute their local contact list name for whatever is provided by the calling name service. This means that if stir succeeds in improving the quality of the calling party number, but no solution is provided for calling party name, fraudsters may still be able to disguise their activities. >>>>> >>>>> This work proposes to change how caller name is carried to using the existing display name portion of the SIP URI in the From or P-A-I field. The name would be carried in the signaling from origination to termination. This capability exists today, although the service providers typically do not restrict or asses what name the caller asserts. Therefore, along with the name would come a form of validation that the name is genuine, and, for calls from businesses, the type of business it is from. >>>>> >>>>> Validation of names is exceedingly difficult, and this work does not propose a solution that will provide a name with absolute certainty that it is genuine and associated with the telephone number of the calling party. It does propose that the data be vetted through some process, which may not result in a simple "this is the name" result. Rather, the vetting process may provide a name, but accompany it with a confidence factor(score) indicating the source's assessment of the likelihood that the name is represents the calling party. Confidence would be a simple 0-100 scaler, without an attempt to precisely define or normalize it between sources. That means that the termination side would have to evaluate the confidence factor and the source of the confidence together to decide how much to trust the name. The termination could take a variety of actions based on the source and the claimed confidence. Doing so implies that the number of sources is limited so that eval uati >>>> ng >>>>> the source for trustworthiness can be accomplished. >>>>> >>>>> Vetting the name at the source is more likely to be of value, because the source may have a variety of other information about the party the name is assigned to that can be used to improve the reliability of the vetting process. For example, address, other phone numbers, age, email addresses, domains (for businesses), etc can be used to provide much higher confidence that the name accurately represents the calling party than just the number known at the termination side. >>>>> >>>>> Besides the name, when a call is made from a business, the type of business can provide important information to the caller when deciding to answer the call, or trust the caller. The type of business would be a selection from an existing taxonomy of business types and would be relatively high level ("bank", "florist", "doctor"). >>>>> >>>>> The name, type of business (if appropriate), the source of the data, the confidence indicator and some indication of the vetting process would accompany the name in a new header in a secure manner -- secure in the sense that the number, the name, type, the source, and the sources' asserted confidence of the name is signed by the source. >>>>> >>>>> If the termination side did not trust the source, or it did, but the confidence was too low in its opinion, the termination may take a number of actions, including, but not limited to: >>>>> a) Refuse the call, or send it to voicemail >>>>> b) Use an independent source of names, like the alternative name suppliers that exist today to display an alternate name >>>>> c) Provide a visual or audible warning to the user that the name may not be valid >>>>> d) Provide a visual or audible representation of the confidence, possibly simplified (red/orange/yellow/green) >>>>> e) Provide a caller feedback (thumbs up/down) mechanism to further develop a rating of the source, or the specific name/number pair >>>>> >>>>> Brian >>>>> >>>>> >>>>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: >>>>> >>>>>> I didn't want to get into solution space, but I'm a bit surprised by the question, since that's exactly what's been discussed, at length. The idea was that, unlike today, the textual callerID is generally traceable to the originating carrier and/or originating entity, for the Organization/From split I provided as an example earlier. >>>>>> >>>>>> As pointed out, that's not always true today, given that the destination has no clue which database is being used and who inserted the information there - a tier-1 carrier based on business records, listyourself.net based on caller assertion or some random white pages service based on who-knows. >>>>>> >>>>>> For the additional information, we have, as pointed out repeatedly, numerous third-party databases, both private and governmental. The originating carrier or possibly the originator can obtain and sign that information as a value-add. The ARID approach is another possibility. >>>>>> >>>>>> I've tried to provide very specific examples of how this could work, but am obviously not getting the point across. >>>>>> >>>>>> ________________________________________ >>>>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>>>> Sent: Monday, September 02, 2013 11:51 AM >>>>>> To: Henning Schulzrinne >>>>>> Cc: Stephen Farrell; cnit@ietf.org >>>>>> Subject: Re: [cnit] what's the actual problem here? >>>>>> >>>>>> >>>>>>> (b) indicate provenance of the information (e.g., was this inserted by the caller, the caller's carrier or by the receiving carrier, CNAM-style) >>>>>> >>>>>> I think that might be actually quite hard to accomplish, in a trustworthy manner. The terminating carrier would know whether it got the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where the LIDB data ultimately came from other than the LIDB AS for the calling number. >>>>>> >>>>>> Since the premise for this discussion is that calling names are not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their data be populated by untrustworthy sources. Is that correct? >>>>>> >>>>>> >>>>>> >>>>>> -hadriel >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >> > > From pkyzivat@alum.mit.edu Wed Sep 4 12:57:11 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CAB21E809D for ; Wed, 4 Sep 2013 12:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.041 X-Spam-Level: X-Spam-Status: No, score=-0.041 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2WX7xbFb2wK for ; Wed, 4 Sep 2013 12:56:55 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 356C821F8B07 for ; Wed, 4 Sep 2013 12:56:51 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id M4Hq1m0040mv7h0547wrjb; Wed, 04 Sep 2013 19:56:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id M7wr1m00V3ZTu2S3X7wrVB; Wed, 04 Sep 2013 19:56:51 +0000 Message-ID: <52279082.9050901@alum.mit.edu> Date: Wed, 04 Sep 2013 15:56:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: cnit@ietf.org References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <65358661-ED23-4D4F-9293-624EA007EE91@brianrosen.net> In-Reply-To: <65358661-ED23-4D4F-9293-624EA007EE91@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378324611; bh=yCrfKO3+/PqFTYjga+OrtfrfznADrVArJg+lIj0L6Lk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=B+07C0Fx02y6s4fHJ2S4PJaMpNhd/o+2G9giUnwpfmbMPCNHZ8d9PAPRgKETf7D6Y mza5QbsTMANEOICfs4Ixxu8nqTMQ+LavcGNCyYn4wAV29ETAJgxovaQWtMjuLg927H 9qoj/r/LjMoRV5kaaWT8QSjqddYzbPsIZ+gjz0zMho+p+bGk4swygb0912i+UtBZKx 15Dn4NIrRjnzpQRksxeclFKpAnwEKfH5HvVO0xftPx4FzrATevcY4QrXw7GFzlJwJ+ Ilqs55O0Yawmncg/cVNiCTT2cGqMwYOwkfxJpWGk0G3v2KWBlBmAP2JimMDn4gFbts C488qPuhpgT/w== Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:57:11 -0000 On 9/4/13 1:19 PM, Brian Rosen wrote: > The architectural difference is that the data is carried in the signaling, not queried by the termination side. > > Today, each provider loads the data with whatever it wants in the way of validation. We propose to carry the identity of the validation, and the type of validation provided, in the signaling, in the hope that providers will use a relatively small number of 3rd party validation services instead of, or in addition to, any validation they do now. > > Peering arrangements could cover this kind of thing to. A "green" provider could have a requirement that calls coming into its network have a name validated by an acceptable (to it) validation source. > > A termination network might suppress names that weren't from a source it trusted. ISTM that here you are describing a system in which the callee's provider is doing a validation on the callee's behalf, possibly based on data provided by others. That gives me somebody I can blame that I have a contractual relationship with. Thanks, Paul > Brian > > On Sep 4, 2013, at 12:04 PM, Hadriel Kaplan wrote: > >> >> I asked the question because it seems to me there's a contradiction in here somewhere. >> >> From a 10k foot view, the current LIDB model is essentially the model being proposed as the solution. Not the pricing model, maybe, but the architectural model. >> >> The model being proposed is "the originator uses a name validation service that provides some assertion about the originating text name, and everyone else trusts that validation service's assertion". That sure sounds like LIDB to me, just with different powerpoint slide icons. The LIDB AS runs the database for its phone number customers, and in theory the AS should audit/verify the contents of its name entries to be valid. It also provides a lot more than simply calling name data today, and if we think it needs even more information then we can talk about that. >> >> But if bad names are entering the LIDB databases, then I don't know why we think they won't enter whatever "validation service" we're talking about. Sure they might not enter TARGUSinfo databases, but there's no reason to think everyone will start using TARGUSinfo for their validation service. For example why wouldn't the existing LIDB AS providers simply market themselves as a "validation service" to their existing customers? And since some Tier-1 carriers run their own LIDB AS, why would they switch to someone else? >> >> If the answer to that is "well no one would trust claimed names from LIDB AS", I find that hard to believe, since they appear to be trusted sufficiently right now; and it's not in the power of the terminating carriers to force the originating carriers to use a different LIDB AS. >> >> Ultimately if this whole thing just boils down to "we don't know how this name got into the DB", then add a field to LIDB identifying the source... if an existing field doesn't already do that. (what does the "Account Owner" field hold?) >> >> The other "problem" I've heard about LIDB is the pricing model, but that's a separate issue. >> >> -hadriel >> >> >> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: >> >>> I didn't want to get into solution space, but I'm a bit surprised by the question, since that's exactly what's been discussed, at length. The idea was that, unlike today, the textual callerID is generally traceable to the originating carrier and/or originating entity, for the Organization/From split I provided as an example earlier. >>> >>> As pointed out, that's not always true today, given that the destination has no clue which database is being used and who inserted the information there - a tier-1 carrier based on business records, listyourself.net based on caller assertion or some random white pages service based on who-knows. >>> >>> For the additional information, we have, as pointed out repeatedly, numerous third-party databases, both private and governmental. The originating carrier or possibly the originator can obtain and sign that information as a value-add. The ARID approach is another possibility. >>> >>> I've tried to provide very specific examples of how this could work, but am obviously not getting the point across. >>> >>> ________________________________________ >>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>> Sent: Monday, September 02, 2013 11:51 AM >>> To: Henning Schulzrinne >>> Cc: Stephen Farrell; cnit@ietf.org >>> Subject: Re: [cnit] what's the actual problem here? >>> >>> >>>> (b) indicate provenance of the information (e.g., was this inserted by the caller, the caller's carrier or by the receiving carrier, CNAM-style) >>> >>> I think that might be actually quite hard to accomplish, in a trustworthy manner. The terminating carrier would know whether it got the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where the LIDB data ultimately came from other than the LIDB AS for the calling number. >>> >>> Since the premise for this discussion is that calling names are not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their data be populated by untrustworthy sources. Is that correct? >>> >>> >>> >>> -hadriel >>> >>> _______________________________________________ >>> 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 > From br@brianrosen.net Wed Sep 4 13:03:15 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF67021E814D for ; Wed, 4 Sep 2013 13:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSbs+jXmcZLo for ; Wed, 4 Sep 2013 13:03:11 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id DDDCB21E80E6 for ; Wed, 4 Sep 2013 13:03:10 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id gh4so455521qeb.2 for ; Wed, 04 Sep 2013 13:03:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Zauao22vvg/Z/H3OSZcoFdfprU/lG2GVzzBnobZYMLk=; b=UW85RwckHvKgsbTR0jO8V79GvbENm3r37w/HRncAXVRYpOCqHBjugpQtwcpBxgmzLX jjhyUXmh2d+iUKcatPiQ3fFkvhqpMLBPPxB99qTBngoXkfUtSlSKybYG6yk5oL+y1YFR 0cXHSmjkEKo3/HoUUEFJXITHFfAn9uAT7MHOQQG2L8Erjl0LOm4kGmAcVrsovw9e0ViG a4J320o2CAvPBzyZPPpXgdvdg1mwbjy6T37x3c58OBdWLRdogJtyPXzZNbd5G8jYpc+6 T1LA/DsxCZkBtqWxzExNXvLrdNkegyzHEJQj3T8gS9tuXWuURI1jy+aKD+IxQOnK5Qyl zinw== X-Gm-Message-State: ALoCoQl+w3bwXZuvJBwpLlt5lY+Kt41pvOe9nQHLdhBqVJOqJ3LtkaCDgY8ULMBkFMjPEwHLLVk9 X-Received: by 10.224.137.4 with SMTP id u4mr5540772qat.69.1378324989339; Wed, 04 Sep 2013 13:03:09 -0700 (PDT) Received: from [10.33.203.84] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id q18sm35820327qad.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 13:03:08 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <52278EE6.1090400@alum.mit.edu> Date: Wed, 4 Sep 2013 16:03:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52278EE6.1090400@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 20:03:15 -0000 While I think the situation could be the same - your provider handles it = all, and you only see either "unknown" or a name, I think it will be = more probable that your device provider wants the data to make better = use of it than your provider could (since it's actions are more = limited). You still look to your provider (or device/app supplier). = You don't look to the origination provider. Brian On Sep 4, 2013, at 3:49 PM, Paul Kyzivat wrote: > Brian, >=20 > My issue is with the trust model. Today this is a service offered by = my provider. If there are problems, I would complain to my provider. It = may be that my provider gets the data from a DB that was populated by = the calling provider, but that is not *my* problem. >=20 > IIUC, in what you are proposing, the data I get will be signed by the = caller or calling provider. Then I must decide whether to trust that. = And if there are problems, then I presumably need to take it up with = that provider. >=20 > Thanks, > Paul >=20 > On 9/3/13 4:04 PM, Brian Rosen wrote: >> So you want to cut the originating provider, who has the most = information available to validate the number, completely out of the = loop? >>=20 >> We have this service now, and it's fairly good. Instead of paying = the origination provider for the LIDB dip, they pay us to dip out = database with the number. But because the only input to validation is = phone number, what comes out is variable quality. It also has a = specific problem that new service is very hard to accommodate. Until = the number is in use within the sources of data the database uses, the = entry would be considered unknown. That's not a huge problem to anyone = but the new customer. >>=20 >> So the objection I have to termination side DB dip is that the = quality of validation is constrained by the limited amount of = information in the query. If I do validation on the origination, I get = much better results. That, by the way, is independent of any score that = might be sent in the signaling. >>=20 >> Brian >>=20 >>=20 >> On Sep 3, 2013, at 3:54 PM, Paul Kyzivat = wrote: >>=20 >>> On 9/3/13 3:36 PM, Brian Rosen wrote: >>>> Henning proposed to have some standardization of "method", but he = meant broad categories like "from billing records". That probably = doesn't help you, but I liked that idea. >>>>=20 >>>> Without the validation, how would we change anything? As it exists = now, both the display name, if sent, and the content of the CNAM = database can easily be anything you want if you use a pink carrier. How = would you propose to fix that? >>>=20 >>> As a user of this service, I would be more comfortable with it done = by an agent for the callee, based on number lookup. At least then the = callee has somebody to blame, and hopefully can choose which one. >>>=20 >>> At least this way the callee has a contract with *somebody* that = will say *something* about the level of trust in the data, and a = recourse if it turns out to be wrong. >>>=20 >>> I'm imagining that companies like Neustar would offer this service, = either directly to the end user, or to the provider for the callee. And = companies like Google might also provide a service like this. The = interface to the service need not be standardized. On smart phones you = could install a call validation app that plugs into incoming call = handling, and manages its own display of the information. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Brian >>>>=20 >>>> On Sep 3, 2013, at 3:31 PM, Paul Kyzivat = wrote: >>>>=20 >>>>> Nits: >>>>>=20 >>>>> s/arose/arisen/ >>>>> s/scaler/scalar/ >>>>>=20 >>>>> Substance: >>>>>=20 >>>>> I'm still not buying the trust chain that says: >>>>>=20 >>>>> - caller supplies the name >>>>> - caller's provider provides the validation of the name, >>>>> using an undefined method and scale >>>>> - callee decides how to trust the name based on the >>>>> provided score and trust in the signer >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>> On 9/3/13 1:32 PM, Brian Rosen wrote: >>>>>> I'm going to try and restate the "what is the problem", working = off what has been said. >>>>>>=20 >>>>>> In the PSTN today, there is an optional service that will display = the name of the caller. The name is currently obtained from a database. = Historically, the database is operated by the originating carrier, and = is populated with the name obtained from the billing and service data = used to establish the service. The database is queried by the = terminating carrier with the phone number to obtain the name. Recently, = due to charges levied on the terminating carrier by the originating = carrier to query the database, alternatives have arose where large = consumer oriented databases are queried that independently match name = with telephone number without reference to the originating carrier's = information. When the databases were operated by large established = telcos, the reliability of the data was good. However, some service = providers are now lax in how the data is populated, and some even = advertise the ability to allow any name to be used with a number. This = has significantly erod >>>>> ed >>>>>> the usefulness of the service. Where caller name service is = provided, it replaces the display of the calling party number, although = smart phones will usually substitute their local contact list name for = whatever is provided by the calling name service. This means that if = stir succeeds in improving the quality of the calling party number, but = no solution is provided for calling party name, fraudsters may still be = able to disguise their activities. >>>>>>=20 >>>>>> This work proposes to change how caller name is carried to using = the existing display name portion of the SIP URI in the =46rom or P-A-I = field. The name would be carried in the signaling from origination to = termination. This capability exists today, although the service = providers typically do not restrict or asses what name the caller = asserts. Therefore, along with the name would come a form of validation = that the name is genuine, and, for calls from businesses, the type of = business it is from. >>>>>>=20 >>>>>> Validation of names is exceedingly difficult, and this work does = not propose a solution that will provide a name with absolute certainty = that it is genuine and associated with the telephone number of the = calling party. It does propose that the data be vetted through some = process, which may not result in a simple "this is the name" result. = Rather, the vetting process may provide a name, but accompany it with a = confidence factor(score) indicating the source's assessment of the = likelihood that the name is represents the calling party. Confidence = would be a simple 0-100 scaler, without an attempt to precisely define = or normalize it between sources. That means that the termination side = would have to evaluate the confidence factor and the source of the = confidence together to decide how much to trust the name. The = termination could take a variety of actions based on the source and the = claimed confidence. Doing so implies that the number of sources is = limited so that evaluati >>>>> ng >>>>>> the source for trustworthiness can be accomplished. >>>>>>=20 >>>>>> Vetting the name at the source is more likely to be of value, = because the source may have a variety of other information about the = party the name is assigned to that can be used to improve the = reliability of the vetting process. For example, address, other phone = numbers, age, email addresses, domains (for businesses), etc can be used = to provide much higher confidence that the name accurately represents = the calling party than just the number known at the termination side. >>>>>>=20 >>>>>> Besides the name, when a call is made from a business, the type = of business can provide important information to the caller when = deciding to answer the call, or trust the caller. The type of business = would be a selection from an existing taxonomy of business types and = would be relatively high level ("bank", "florist", "doctor"). >>>>>>=20 >>>>>> The name, type of business (if appropriate), the source of the = data, the confidence indicator and some indication of the vetting = process would accompany the name in a new header in a secure manner -- = secure in the sense that the number, the name, type, the source, and the = sources' asserted confidence of the name is signed by the source. >>>>>>=20 >>>>>> If the termination side did not trust the source, or it did, but = the confidence was too low in its opinion, the termination may take a = number of actions, including, but not limited to: >>>>>> a) Refuse the call, or send it to voicemail >>>>>> b) Use an independent source of names, like the alternative name = suppliers that exist today to display an alternate name >>>>>> c) Provide a visual or audible warning to the user that the name = may not be valid >>>>>> d) Provide a visual or audible representation of the confidence, = possibly simplified (red/orange/yellow/green) >>>>>> e) Provide a caller feedback (thumbs up/down) mechanism to = further develop a rating of the source, or the specific name/number pair >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne = wrote: >>>>>>=20 >>>>>>> I didn't want to get into solution space, but I'm a bit = surprised by the question, since that's exactly what's been discussed, = at length. The idea was that, unlike today, the textual callerID is = generally traceable to the originating carrier and/or originating = entity, for the Organization/=46rom split I provided as an example = earlier. >>>>>>>=20 >>>>>>> As pointed out, that's not always true today, given that the = destination has no clue which database is being used and who inserted = the information there - a tier-1 carrier based on business records, = listyourself.net based on caller assertion or some random white pages = service based on who-knows. >>>>>>>=20 >>>>>>> For the additional information, we have, as pointed out = repeatedly, numerous third-party databases, both private and = governmental. The originating carrier or possibly the originator can = obtain and sign that information as a value-add. The ARID approach is = another possibility. >>>>>>>=20 >>>>>>> I've tried to provide very specific examples of how this could = work, but am obviously not getting the point across. >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>>>>> Sent: Monday, September 02, 2013 11:51 AM >>>>>>> To: Henning Schulzrinne >>>>>>> Cc: Stephen Farrell; cnit@ietf.org >>>>>>> Subject: Re: [cnit] what's the actual problem here? >>>>>>>=20 >>>>>>>=20 >>>>>>>> (b) indicate provenance of the information (e.g., was this = inserted by the caller, the caller's carrier or by the receiving = carrier, CNAM-style) >>>>>>>=20 >>>>>>> I think that might be actually quite hard to accomplish, in a = trustworthy manner. The terminating carrier would know whether it got = the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it = doesn't know where the LIDB data ultimately came from other than the = LIDB AS for the calling number. >>>>>>>=20 >>>>>>> Since the premise for this discussion is that calling names are = not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting = their data be populated by untrustworthy sources. Is that correct? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -hadriel >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> cnit mailing list >>>>>>> cnit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>>>=20 >>>>>> _______________________________________________ >>>>>> cnit mailing list >>>>>> cnit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> cnit mailing list >>>>> cnit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 From hala.mowafy@ericsson.com Wed Sep 4 13:44:51 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F1D11E81F7 for ; Wed, 4 Sep 2013 13:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=1.691, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD3lti6QF0Za for ; Wed, 4 Sep 2013 13:44:46 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 10FFF11E81F4 for ; Wed, 4 Sep 2013 13:44:46 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-ba-52279bbcd303 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id EA.DB.03458.CBB97225; Wed, 4 Sep 2013 22:44:45 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Wed, 4 Sep 2013 16:44:44 -0400 From: Hala Mowafy To: Hadriel Kaplan , Henning Schulzrinne Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOpo/ihSvGsOHCgUiEYFTUCt4llpmxlP0AgAFJaQCAALUCgIACc1wAgAABa7A= Date: Wed, 4 Sep 2013 20:44:43 +0000 Message-ID: <728F35AE98AEDB4A96FF3A32A85A60BB117F0909@eusaamb105.ericsson.se> References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPrO7e2epBBu/fCFtcnb2P0eLTpk/M Fj+P7Ga1mL73GrsDi8fa7qtsHrdvv2HzWLLkJ5PHx6e3WAJYorhsUlJzMstSi/TtErgylh/u YC7YZF9xYdtClgbGtcZdjJwcEgImEotfTmCGsMUkLtxbz9bFyMUhJHCUUeL/1u8sEM4yRold r3YxglSxCehIzPn7EaxDRCBZYsGbJSwgNrNAkMSb/ilMILawgLHE6WtP2SBqTCROHl7CCmH7 SbQunQlmswioSNw6NAeshlfAV2LJsbOMEMt+M0qs3fERKMHBwSlgJ/FpnhVIDSPQdd9PrWGC 2CUucevJfCaIqwUkluw5D/WBqMTLx/9YIWxlie9zHkHdpiOxYPcnNghbW2LZwtfMEHsFJU7O fMIygVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UaGmxiB8XRMgs1xB+OCT5aHGKU5WJTE eTfonQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLj+8Wyn0Gi7Kbq+z0Lmau2OK97EnhVz 2vXH3EKp3zZTNl40P2BrG74vpXVxWMv3Ojmm7mw7fRmvNXIK8fPVLj3RvbVq3Yx1dmei1S0m 6UwMvqCm2Mu7VUvpl6/2WtUD6b9Mo1qex+nsuM/QvOTO67oZTxui6pz5nrx7MqHWeM+t1jnb LvjUqCixFGckGmoxFxUnAgB47sbQdQIAAA== Cc: "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 20:44:51 -0000 Hadriel, I worked on LIDB's architecture and services for a number of years and I'd = like to offer a few points of clarification: - When talking about a LIDB operated by the traditional carriers in the U.S= . (e.g., AT&T) the data stored in LIDB is derived from the service order an= d the direct relationship the carrier has with each customer - not from mai= ling lists or credit bureaus. Third party databases - because in most case= s they have no direct relation with the end user - tend to use a variety of= marketing sources, as such. I cannot speak of TARGUSinfo (now Neustar) or= any other entrepreneur out there that created a database from the white pa= ges but later on failed to update the records in a timely fashion. Some ar= e better than others, of course. - However, it is worth noting that in my 10 years on LIDB, whenever our tea= m received field trouble reports on CNAM (customers complaining about recei= ving incorrect names, names of people long dead, etc.) the result of the in= vestigations pointed to third party databases containing aged data - more t= han 95% of the time. No exaggeration! - The role of the LIDB Administration System (AS) - as Ken pointed out - is= to maintain the master files (if you will) and provision the LIDB line rec= ords. The AS also updates LIDB any time a change occurs with the account, = again based on any changes the customer makes in his/her service profile. = The AS periodically audits LIDB line records against the customers' billing= records to ensure no data entry/human errors occurred, etc. The LIDB admi= nistrators go to great lengths to maintain the integrity and accuracy of th= e data in LIDB and do not simply accept variations of the name on a whim. - To your question: The AO or account owner is a data parameter on each LI= DB line record that contains the SPID or service provider ID responsible fo= r that account. =20 - When you mentioned "validation service" I chuckled because there is a com= pletely different service that LIDB offers called "Validation Service" but = it is not what CNIT or STIR is thinking of (certifications and all). Inste= ad it is a validation of customer data (name, billing address, phone number= , preferred language, ZIP Code, and more) that some retailers and banks hav= e started using to help reduce their online retail fraud. In the area of V= alidation Service, LIDB sometimes competes with and sometimes complements a= large number of other data sources that retailers use. From working with = members of the Merchant Risk Council (MRC) for over 3 years, the feedback I= got was that they received better accuracy ratings when they trialed LIDB = than they did with other sources for various sets of data. =20 - I really don't like talking about pricing models in this venue because bu= siness decisions should drive that. However, given that my company does n= ot own a LIDB, I feel a little better offering this observation from my ind= ustry interactions regarding LIDB's pricing model:- Most people are still = under the impression that LIDB query prices are exorbitant (a few pennies p= er query back in the 1980s) when indeed it is a fraction of a U.S. penny fo= r CNAM and the Validation Services today. =20 Hala -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Wednesday, September 04, 2013 12:04 PM To: Henning Schulzrinne Cc: cnit@ietf.org; Stephen Farrell Subject: Re: [cnit] what's the actual problem here? I asked the question because it seems to me there's a contradiction in here= somewhere. >From a 10k foot view, the current LIDB model is essentially the model being= proposed as the solution. Not the pricing model, maybe, but the architect= ural model. The model being proposed is "the originator uses a name validation service = that provides some assertion about the originating text name, and everyone = else trusts that validation service's assertion". That sure sounds like LI= DB to me, just with different powerpoint slide icons. The LIDB AS runs the= database for its phone number customers, and in theory the AS should audit= /verify the contents of its name entries to be valid. It also provides a l= ot more than simply calling name data today, and if we think it needs even = more information then we can talk about that. But if bad names are entering the LIDB databases, then I don't know why we = think they won't enter whatever "validation service" we're talking about. = Sure they might not enter TARGUSinfo databases, but there's no reason to th= ink everyone will start using TARGUSinfo for their validation service. For= example why wouldn't the existing LIDB AS providers simply market themselv= es as a "validation service" to their existing customers? And since some T= ier-1 carriers run their own LIDB AS, why would they switch to someone else= ? If the answer to that is "well no one would trust claimed names from LIDB A= S", I find that hard to believe, since they appear to be trusted sufficient= ly right now; and it's not in the power of the terminating carriers to forc= e the originating carriers to use a different LIDB AS. Ultimately if this whole thing just boils down to "we don't know how this n= ame got into the DB", then add a field to LIDB identifying the source... if= an existing field doesn't already do that. (what does the "Account Owner" = field hold?) The other "problem" I've heard about LIDB is the pricing model, but that's = a separate issue. -hadriel On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: > I didn't want to get into solution space, but I'm a bit surprised by the = question, since that's exactly what's been discussed, at length. The idea w= as that, unlike today, the textual callerID is generally traceable to the o= riginating carrier and/or originating entity, for the Organization/From spl= it I provided as an example earlier. >=20 > As pointed out, that's not always true today, given that the destination = has no clue which database is being used and who inserted the information t= here - a tier-1 carrier based on business records, listyourself.net based o= n caller assertion or some random white pages service based on who-knows. >=20 > For the additional information, we have, as pointed out repeatedly, numer= ous third-party databases, both private and governmental. The originating c= arrier or possibly the originator can obtain and sign that information as a= value-add. The ARID approach is another possibility. >=20 > I've tried to provide very specific examples of how this could work, but = am obviously not getting the point across. >=20 > ________________________________________ > From: Hadriel Kaplan [hadriel.kaplan@oracle.com] > Sent: Monday, September 02, 2013 11:51 AM > To: Henning Schulzrinne > Cc: Stephen Farrell; cnit@ietf.org > Subject: Re: [cnit] what's the actual problem here? >=20 >=20 >> (b) indicate provenance of the information (e.g., was this inserted by t= he caller, the caller's carrier or by the receiving carrier, CNAM-style) >=20 > I think that might be actually quite hard to accomplish, in a trustworthy= manner. The terminating carrier would know whether it got the name from a= LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where th= e LIDB data ultimately came from other than the LIDB AS for the calling num= ber. >=20 > Since the premise for this discussion is that calling names are not trust= worthy anymore (?), I'm assuming the LIDB AS'es are letting their data be p= opulated by untrustworthy sources. Is that correct? >=20 >=20 >=20 > -hadriel >=20 > _______________________________________________ > 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 From Henning.Schulzrinne@fcc.gov Wed Sep 4 14:03:35 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9514A11E8101 for ; Wed, 4 Sep 2013 14:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lskMjeIL0nEG for ; Wed, 4 Sep 2013 14:03:31 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 52B7C21F9E12 for ; Wed, 4 Sep 2013 14:03:30 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' , Paul Kyzivat Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgAGP9QCAAG6AkoABQEIAgAAhGoCAAAF1AIAABRgAgAACroCAAY5QAIAAA6sA///L1MA= Date: Wed, 4 Sep 2013 21:03:28 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52278EE6.1090400@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 21:03:35 -0000 Today, we have two cases, neither of which has a satisfactory outcome: (1) Good original provider, bad (or cheap) callee provider: The injured par= ty is the business whose display is inaccurate or missing; they have no rea= sonable way of fixing the problem. The callee likely believes that they see= information provided by the origin provider, and I suspect that, if they h= ad too much time on their hand and complain to their local service provider= , the customer service rep would not know how callerID works and would be h= appy to blame the caller. In most cases, they have no way of knowing whethe= r the information is right, wrong or missing for a good reason. (2) Bad original data, good callee service provider: The callee service pro= vider can't do anything about the pick-your-own-text providers, as most of = the data even for those services is probably still accurate, so they can't = just drop those names. Again, no reasonable remedy. Thus, the current system seems pessimal - the entities that are incented an= d knowledgeable can't fix problems.=20 Henning -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Wednesday, September 04, 2013 4:03 PM To: Paul Kyzivat Cc: cnit@ietf.org Subject: Re: [cnit] what's the actual problem here? While I think the situation could be the same - your provider handles it al= l, and you only see either "unknown" or a name, I think it will be more pr= obable that your device provider wants the data to make better use of it th= an your provider could (since it's actions are more limited). You still lo= ok to your provider (or device/app supplier). You don't look to the origin= ation provider. Brian On Sep 4, 2013, at 3:49 PM, Paul Kyzivat wrote: > Brian, >=20 > My issue is with the trust model. Today this is a service offered by my p= rovider. If there are problems, I would complain to my provider. It may be = that my provider gets the data from a DB that was populated by the calling = provider, but that is not *my* problem. >=20 > IIUC, in what you are proposing, the data I get will be signed by the cal= ler or calling provider. Then I must decide whether to trust that. And if t= here are problems, then I presumably need to take it up with that provider. >=20 > Thanks, > Paul >=20 > On 9/3/13 4:04 PM, Brian Rosen wrote: >> So you want to cut the originating provider, who has the most informatio= n available to validate the number, completely out of the loop? >>=20 >> We have this service now, and it's fairly good. Instead of paying the = origination provider for the LIDB dip, they pay us to dip out database with= the number. But because the only input to validation is phone number, wha= t comes out is variable quality. It also has a specific problem that new s= ervice is very hard to accommodate. Until the number is in use within the = sources of data the database uses, the entry would be considered unknown. = That's not a huge problem to anyone but the new customer. >>=20 >> So the objection I have to termination side DB dip is that the quality o= f validation is constrained by the limited amount of information in the que= ry. If I do validation on the origination, I get much better results. Tha= t, by the way, is independent of any score that might be sent in the signal= ing. >>=20 >> Brian >>=20 >>=20 >> On Sep 3, 2013, at 3:54 PM, Paul Kyzivat wrote: >>=20 >>> On 9/3/13 3:36 PM, Brian Rosen wrote: >>>> Henning proposed to have some standardization of "method", but he mean= t broad categories like "from billing records". That probably doesn't help= you, but I liked that idea. >>>>=20 >>>> Without the validation, how would we change anything? As it exists no= w, both the display name, if sent, and the content of the CNAM database can= easily be anything you want if you use a pink carrier. How would you prop= ose to fix that? >>>=20 >>> As a user of this service, I would be more comfortable with it done by = an agent for the callee, based on number lookup. At least then the callee h= as somebody to blame, and hopefully can choose which one. >>>=20 >>> At least this way the callee has a contract with *somebody* that will s= ay *something* about the level of trust in the data, and a recourse if it t= urns out to be wrong. >>>=20 >>> I'm imagining that companies like Neustar would offer this service, eit= her directly to the end user, or to the provider for the callee. And compan= ies like Google might also provide a service like this. The interface to th= e service need not be standardized. On smart phones you could install a cal= l validation app that plugs into incoming call handling, and manages its ow= n display of the information. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Brian >>>>=20 >>>> On Sep 3, 2013, at 3:31 PM, Paul Kyzivat wrote= : >>>>=20 >>>>> Nits: >>>>>=20 >>>>> s/arose/arisen/ >>>>> s/scaler/scalar/ >>>>>=20 >>>>> Substance: >>>>>=20 >>>>> I'm still not buying the trust chain that says: >>>>>=20 >>>>> - caller supplies the name >>>>> - caller's provider provides the validation of the name, using an=20 >>>>> undefined method and scale >>>>> - callee decides how to trust the name based on the provided=20 >>>>> score and trust in the signer >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>> On 9/3/13 1:32 PM, Brian Rosen wrote: >>>>>> I'm going to try and restate the "what is the problem", working off = what has been said. >>>>>>=20 >>>>>> In the PSTN today, there is an optional service that will display=20 >>>>>> the name of the caller. The name is currently obtained from a=20 >>>>>> database. Historically, the database is operated by the=20 >>>>>> originating carrier, and is populated with the name obtained from=20 >>>>>> the billing and service data used to establish the service. The=20 >>>>>> database is queried by the terminating carrier with the phone=20 >>>>>> number to obtain the name. Recently, due to charges levied on=20 >>>>>> the terminating carrier by the originating carrier to query the=20 >>>>>> database, alternatives have arose where large consumer oriented=20 >>>>>> databases are queried that independently match name with=20 >>>>>> telephone number without reference to the originating carrier's=20 >>>>>> information. When the databases were operated by large=20 >>>>>> established telcos, the reliability of the data was good. =20 >>>>>> However, some service providers are now lax in how the data is=20 >>>>>> populated, and some even advertise the ability to allow any name=20 >>>>>> to be used with a number. This has significantly erod >>>>> ed >>>>>> the usefulness of the service. Where caller name service is provi= ded, it replaces the display of the calling party number, although smart ph= ones will usually substitute their local contact list name for whatever is = provided by the calling name service. This means that if stir succeeds in = improving the quality of the calling party number, but no solution is provi= ded for calling party name, fraudsters may still be able to disguise their = activities. >>>>>>=20 >>>>>> This work proposes to change how caller name is carried to using the= existing display name portion of the SIP URI in the From or P-A-I field. = The name would be carried in the signaling from origination to termination.= This capability exists today, although the service providers typically do= not restrict or asses what name the caller asserts. Therefore, along with= the name would come a form of validation that the name is genuine, and, fo= r calls from businesses, the type of business it is from. >>>>>>=20 >>>>>> Validation of names is exceedingly difficult, and this work does=20 >>>>>> not propose a solution that will provide a name with absolute=20 >>>>>> certainty that it is genuine and associated with the telephone=20 >>>>>> number of the calling party. It does propose that the data be=20 >>>>>> vetted through some process, which may not result in a simple=20 >>>>>> "this is the name" result. Rather, the vetting process may=20 >>>>>> provide a name, but accompany it with a confidence factor(score)=20 >>>>>> indicating the source's assessment of the likelihood that the=20 >>>>>> name is represents the calling party. Confidence would be a=20 >>>>>> simple 0-100 scaler, without an attempt to precisely define or=20 >>>>>> normalize it between sources. That means that the termination=20 >>>>>> side would have to evaluate the confidence factor and the source=20 >>>>>> of the confidence together to decide how much to trust the name. =20 >>>>>> The termination could take a variety of actions based on the=20 >>>>>> source and the claimed confidence. Doing so implies that the=20 >>>>>> number of sources is limited so that eva luati >>>>> ng >>>>>> the source for trustworthiness can be accomplished. >>>>>>=20 >>>>>> Vetting the name at the source is more likely to be of value, becaus= e the source may have a variety of other information about the party the na= me is assigned to that can be used to improve the reliability of the vettin= g process. For example, address, other phone numbers, age, email addresses= , domains (for businesses), etc can be used to provide much higher confiden= ce that the name accurately represents the calling party than just the numb= er known at the termination side. >>>>>>=20 >>>>>> Besides the name, when a call is made from a business, the type of b= usiness can provide important information to the caller when deciding to an= swer the call, or trust the caller. The type of business would be a select= ion from an existing taxonomy of business types and would be relatively hig= h level ("bank", "florist", "doctor"). >>>>>>=20 >>>>>> The name, type of business (if appropriate), the source of the data,= the confidence indicator and some indication of the vetting process would = accompany the name in a new header in a secure manner -- secure in the sens= e that the number, the name, type, the source, and the sources' asserted co= nfidence of the name is signed by the source. >>>>>>=20 >>>>>> If the termination side did not trust the source, or it did, but the= confidence was too low in its opinion, the termination may take a number o= f actions, including, but not limited to: >>>>>> a) Refuse the call, or send it to voicemail >>>>>> b) Use an independent source of names, like the alternative name=20 >>>>>> suppliers that exist today to display an alternate name >>>>>> c) Provide a visual or audible warning to the user that the name=20 >>>>>> may not be valid >>>>>> d) Provide a visual or audible representation of the confidence,=20 >>>>>> possibly simplified (red/orange/yellow/green) >>>>>> e) Provide a caller feedback (thumbs up/down) mechanism to=20 >>>>>> further develop a rating of the source, or the specific=20 >>>>>> name/number pair >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: >>>>>>=20 >>>>>>> I didn't want to get into solution space, but I'm a bit surprised b= y the question, since that's exactly what's been discussed, at length. The = idea was that, unlike today, the textual callerID is generally traceable to= the originating carrier and/or originating entity, for the Organization/Fr= om split I provided as an example earlier. >>>>>>>=20 >>>>>>> As pointed out, that's not always true today, given that the destin= ation has no clue which database is being used and who inserted the informa= tion there - a tier-1 carrier based on business records, listyourself.net b= ased on caller assertion or some random white pages service based on who-kn= ows. >>>>>>>=20 >>>>>>> For the additional information, we have, as pointed out repeatedly,= numerous third-party databases, both private and governmental. The origina= ting carrier or possibly the originator can obtain and sign that informatio= n as a value-add. The ARID approach is another possibility. >>>>>>>=20 >>>>>>> I've tried to provide very specific examples of how this could work= , but am obviously not getting the point across. >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>>>>> Sent: Monday, September 02, 2013 11:51 AM >>>>>>> To: Henning Schulzrinne >>>>>>> Cc: Stephen Farrell; cnit@ietf.org >>>>>>> Subject: Re: [cnit] what's the actual problem here? >>>>>>>=20 >>>>>>>=20 >>>>>>>> (b) indicate provenance of the information (e.g., was this=20 >>>>>>>> inserted by the caller, the caller's carrier or by the=20 >>>>>>>> receiving carrier, CNAM-style) >>>>>>>=20 >>>>>>> I think that might be actually quite hard to accomplish, in a trust= worthy manner. The terminating carrier would know whether it got the name = from a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know wh= ere the LIDB data ultimately came from other than the LIDB AS for the calli= ng number. >>>>>>>=20 >>>>>>> Since the premise for this discussion is that calling names are not= trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their dat= a be populated by untrustworthy sources. Is that correct? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -hadriel >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> cnit mailing list >>>>>>> cnit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>>>=20 >>>>>> _______________________________________________ >>>>>> cnit mailing list >>>>>> cnit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> cnit mailing list >>>>> cnit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From hadriel.kaplan@oracle.com Wed Sep 4 14:50:14 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85CA21F9815 for ; Wed, 4 Sep 2013 14:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SdR-vCCsDCH for ; Wed, 4 Sep 2013 14:50:08 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 515F721F9B91 for ; Wed, 4 Sep 2013 14:48:55 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r84LmjQ2016937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Sep 2013 21:48:45 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r84LmiPS012443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 21:48:44 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r84LmhVW014844; Wed, 4 Sep 2013 21:48:43 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Sep 2013 14:48:43 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <728F35AE98AEDB4A96FF3A32A85A60BB117F0909@eusaamb105.ericsson.se> Date: Wed, 4 Sep 2013 17:48:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <809B16BC-EDB5-473A-B6AE-E7299797182C@oracle.com> References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <728F35AE98AEDB4A96FF3A32A85A60BB117F0909@eusaamb105.ericsson.se> To: Hala Mowafy X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "cnit@ietf.org" , Stephen Farrell , Henning Schulzrinne Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 21:50:14 -0000 Hi Hala, I'm not sure if you meant those points as countering mine, but I think = they're consistent with what I was saying. No? -hadriel On Sep 4, 2013, at 4:44 PM, Hala Mowafy = wrote: > Hadriel, >=20 > I worked on LIDB's architecture and services for a number of years and = I'd like to offer a few points of clarification: > - When talking about a LIDB operated by the traditional carriers in = the U.S. (e.g., AT&T) the data stored in LIDB is derived from the = service order and the direct relationship the carrier has with each = customer - not from mailing lists or credit bureaus. Third party = databases - because in most cases they have no direct relation with the = end user - tend to use a variety of marketing sources, as such. I = cannot speak of TARGUSinfo (now Neustar) or any other entrepreneur out = there that created a database from the white pages but later on failed = to update the records in a timely fashion. Some are better than others, = of course. > - However, it is worth noting that in my 10 years on LIDB, whenever = our team received field trouble reports on CNAM (customers complaining = about receiving incorrect names, names of people long dead, etc.) the = result of the investigations pointed to third party databases containing = aged data - more than 95% of the time. No exaggeration! > - The role of the LIDB Administration System (AS) - as Ken pointed out = - is to maintain the master files (if you will) and provision the LIDB = line records. The AS also updates LIDB any time a change occurs with = the account, again based on any changes the customer makes in his/her = service profile. The AS periodically audits LIDB line records against = the customers' billing records to ensure no data entry/human errors = occurred, etc. The LIDB administrators go to great lengths to maintain = the integrity and accuracy of the data in LIDB and do not simply accept = variations of the name on a whim. > - To your question: The AO or account owner is a data parameter on = each LIDB line record that contains the SPID or service provider ID = responsible for that account. =20 > - When you mentioned "validation service" I chuckled because there is = a completely different service that LIDB offers called "Validation = Service" but it is not what CNIT or STIR is thinking of (certifications = and all). Instead it is a validation of customer data (name, billing = address, phone number, preferred language, ZIP Code, and more) that some = retailers and banks have started using to help reduce their online = retail fraud. In the area of Validation Service, LIDB sometimes = competes with and sometimes complements a large number of other data = sources that retailers use. =46rom working with members of the Merchant = Risk Council (MRC) for over 3 years, the feedback I got was that they = received better accuracy ratings when they trialed LIDB than they did = with other sources for various sets of data. =20 > - I really don't like talking about pricing models in this venue = because business decisions should drive that. However, given that my = company does not own a LIDB, I feel a little better offering this = observation from my industry interactions regarding LIDB's pricing = model:- Most people are still under the impression that LIDB query = prices are exorbitant (a few pennies per query back in the 1980s) when = indeed it is a fraction of a U.S. penny for CNAM and the Validation = Services today. =20 >=20 > Hala >=20 > -----Original Message----- > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf = Of Hadriel Kaplan > Sent: Wednesday, September 04, 2013 12:04 PM > To: Henning Schulzrinne > Cc: cnit@ietf.org; Stephen Farrell > Subject: Re: [cnit] what's the actual problem here? >=20 >=20 > I asked the question because it seems to me there's a contradiction in = here somewhere. >=20 > =46rom a 10k foot view, the current LIDB model is essentially the = model being proposed as the solution. Not the pricing model, maybe, but = the architectural model. >=20 > The model being proposed is "the originator uses a name validation = service that provides some assertion about the originating text name, = and everyone else trusts that validation service's assertion". That = sure sounds like LIDB to me, just with different powerpoint slide icons. = The LIDB AS runs the database for its phone number customers, and in = theory the AS should audit/verify the contents of its name entries to be = valid. It also provides a lot more than simply calling name data today, = and if we think it needs even more information then we can talk about = that. >=20 > But if bad names are entering the LIDB databases, then I don't know = why we think they won't enter whatever "validation service" we're = talking about. Sure they might not enter TARGUSinfo databases, but = there's no reason to think everyone will start using TARGUSinfo for = their validation service. For example why wouldn't the existing LIDB AS = providers simply market themselves as a "validation service" to their = existing customers? And since some Tier-1 carriers run their own LIDB = AS, why would they switch to someone else? >=20 > If the answer to that is "well no one would trust claimed names from = LIDB AS", I find that hard to believe, since they appear to be trusted = sufficiently right now; and it's not in the power of the terminating = carriers to force the originating carriers to use a different LIDB AS. >=20 > Ultimately if this whole thing just boils down to "we don't know how = this name got into the DB", then add a field to LIDB identifying the = source... if an existing field doesn't already do that. (what does the = "Account Owner" field hold?) >=20 > The other "problem" I've heard about LIDB is the pricing model, but = that's a separate issue. >=20 > -hadriel >=20 >=20 > On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne = wrote: >=20 >> I didn't want to get into solution space, but I'm a bit surprised by = the question, since that's exactly what's been discussed, at length. The = idea was that, unlike today, the textual callerID is generally traceable = to the originating carrier and/or originating entity, for the = Organization/=46rom split I provided as an example earlier. >>=20 >> As pointed out, that's not always true today, given that the = destination has no clue which database is being used and who inserted = the information there - a tier-1 carrier based on business records, = listyourself.net based on caller assertion or some random white pages = service based on who-knows. >>=20 >> For the additional information, we have, as pointed out repeatedly, = numerous third-party databases, both private and governmental. The = originating carrier or possibly the originator can obtain and sign that = information as a value-add. The ARID approach is another possibility. >>=20 >> I've tried to provide very specific examples of how this could work, = but am obviously not getting the point across. >>=20 >> ________________________________________ >> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >> Sent: Monday, September 02, 2013 11:51 AM >> To: Henning Schulzrinne >> Cc: Stephen Farrell; cnit@ietf.org >> Subject: Re: [cnit] what's the actual problem here? >>=20 >>=20 >>> (b) indicate provenance of the information (e.g., was this inserted = by the caller, the caller's carrier or by the receiving carrier, = CNAM-style) >>=20 >> I think that might be actually quite hard to accomplish, in a = trustworthy manner. The terminating carrier would know whether it got = the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it = doesn't know where the LIDB data ultimately came from other than the = LIDB AS for the calling number. >>=20 >> Since the premise for this discussion is that calling names are not = trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their = data be populated by untrustworthy sources. Is that correct? >>=20 >>=20 >>=20 >> -hadriel >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 > _______________________________________________ > 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 From pkyzivat@alum.mit.edu Wed Sep 4 15:24:49 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E6B21E809C for ; Wed, 4 Sep 2013 15:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlILXQ5c9SQE for ; Wed, 4 Sep 2013 15:24:44 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDE221E8093 for ; Wed, 4 Sep 2013 15:24:44 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id Lzov1m00E0mv7h054AQjMR; Wed, 04 Sep 2013 22:24:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id MAQj1m00f3ZTu2S3XAQj5k; Wed, 04 Sep 2013 22:24:43 +0000 Message-ID: <5227B32B.1090905@alum.mit.edu> Date: Wed, 04 Sep 2013 18:24:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52278EE6.1090400@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378333483; bh=tOf7cacCfdB1evO+VPTamYxw1cLSUh9gObPA0HQKcHk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UnSVwe0f5DrHo2FPL4F5MXlla8jnmM44pfvKWWWwIrVcKKOJkmM6qGdy7y6kNon66 1eLsV7XhKsxKuZIa9uSrR3FTdC0Cxr9OyG4GgoWBjXNzrhQl3Bpx+YksPl5+b/mGHI x+9IYog6KUE86pKfh2TLjrMoGZqEl5pBR4mrYHiNu1vJeW3Frkyzhtd0y7XbpLD0lX RoUFvuuPGoeNHMttYwQCJE0+4XyqhGZwCymK90ZlBU3z2A6S63W+QKO/42yrPfxoIT Op6QJzhpNxYFGvI+K+psuAt1F6QamvkY+7/aJ3h6XKKx7liXMAa0cqmgs6uuO2aEtY 17sgaLrshcxlA== Cc: "cnit@ietf.org" , 'Brian Rosen' Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 22:24:49 -0000 On 9/4/13 5:03 PM, Henning Schulzrinne wrote: > Today, we have two cases, neither of which has a satisfactory outcome: > > (1) Good original provider, bad (or cheap) callee provider: The injured party is the business whose display is inaccurate or missing; they have no reasonable way of fixing the problem. The callee likely believes that they see information provided by the origin provider, and I suspect that, if they had too much time on their hand and complain to their local service provider, the customer service rep would not know how callerID works and would be happy to blame the caller. In most cases, they have no way of knowing whether the information is right, wrong or missing for a good reason. > > (2) Bad original data, good callee service provider: The callee service provider can't do anything about the pick-your-own-text providers, as most of the data even for those services is probably still accurate, so they can't just drop those names. Again, no reasonable remedy. Based on Brian's comments, I was thinking that the callee service provider would be making judgement calls on the trustworthiness of the original data it is getting, and excluding that which it deems inadequate to meet the promises it is making to its customers. Then if a customer complains that he isn't getting a name for certain callers, the response (after checking the logs) can be that trustworthy name data is not available for that caller. I'll grant that putting it in the hands of the callee provider has problems for (1). But users of such providers likely have lots of problems. How about a mechanism that allows multiple signatures? Then both the originating and terminating ends could sign. Then the callee looks for a signature by somebody it knows/trusts. The callee provider will sign if it trusts the signature by the caller provider. Thanks, Paul > Thus, the current system seems pessimal - the entities that are incented and knowledgeable can't fix problems. > > Henning > > -----Original Message----- > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Wednesday, September 04, 2013 4:03 PM > To: Paul Kyzivat > Cc: cnit@ietf.org > Subject: Re: [cnit] what's the actual problem here? > > While I think the situation could be the same - your provider handles it all, and you only see either "unknown" or a name, I think it will be more probable that your device provider wants the data to make better use of it than your provider could (since it's actions are more limited). You still look to your provider (or device/app supplier). You don't look to the origination provider. > > Brian > > On Sep 4, 2013, at 3:49 PM, Paul Kyzivat wrote: > >> Brian, >> >> My issue is with the trust model. Today this is a service offered by my provider. If there are problems, I would complain to my provider. It may be that my provider gets the data from a DB that was populated by the calling provider, but that is not *my* problem. >> >> IIUC, in what you are proposing, the data I get will be signed by the caller or calling provider. Then I must decide whether to trust that. And if there are problems, then I presumably need to take it up with that provider. >> >> Thanks, >> Paul >> >> On 9/3/13 4:04 PM, Brian Rosen wrote: >>> So you want to cut the originating provider, who has the most information available to validate the number, completely out of the loop? >>> >>> We have this service now, and it's fairly good. Instead of paying the origination provider for the LIDB dip, they pay us to dip out database with the number. But because the only input to validation is phone number, what comes out is variable quality. It also has a specific problem that new service is very hard to accommodate. Until the number is in use within the sources of data the database uses, the entry would be considered unknown. That's not a huge problem to anyone but the new customer. >>> >>> So the objection I have to termination side DB dip is that the quality of validation is constrained by the limited amount of information in the query. If I do validation on the origination, I get much better results. That, by the way, is independent of any score that might be sent in the signaling. >>> >>> Brian >>> >>> >>> On Sep 3, 2013, at 3:54 PM, Paul Kyzivat wrote: >>> >>>> On 9/3/13 3:36 PM, Brian Rosen wrote: >>>>> Henning proposed to have some standardization of "method", but he meant broad categories like "from billing records". That probably doesn't help you, but I liked that idea. >>>>> >>>>> Without the validation, how would we change anything? As it exists now, both the display name, if sent, and the content of the CNAM database can easily be anything you want if you use a pink carrier. How would you propose to fix that? >>>> >>>> As a user of this service, I would be more comfortable with it done by an agent for the callee, based on number lookup. At least then the callee has somebody to blame, and hopefully can choose which one. >>>> >>>> At least this way the callee has a contract with *somebody* that will say *something* about the level of trust in the data, and a recourse if it turns out to be wrong. >>>> >>>> I'm imagining that companies like Neustar would offer this service, either directly to the end user, or to the provider for the callee. And companies like Google might also provide a service like this. The interface to the service need not be standardized. On smart phones you could install a call validation app that plugs into incoming call handling, and manages its own display of the information. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Brian >>>>> >>>>> On Sep 3, 2013, at 3:31 PM, Paul Kyzivat wrote: >>>>> >>>>>> Nits: >>>>>> >>>>>> s/arose/arisen/ >>>>>> s/scaler/scalar/ >>>>>> >>>>>> Substance: >>>>>> >>>>>> I'm still not buying the trust chain that says: >>>>>> >>>>>> - caller supplies the name >>>>>> - caller's provider provides the validation of the name, using an >>>>>> undefined method and scale >>>>>> - callee decides how to trust the name based on the provided >>>>>> score and trust in the signer >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 9/3/13 1:32 PM, Brian Rosen wrote: >>>>>>> I'm going to try and restate the "what is the problem", working off what has been said. >>>>>>> >>>>>>> In the PSTN today, there is an optional service that will display >>>>>>> the name of the caller. The name is currently obtained from a >>>>>>> database. Historically, the database is operated by the >>>>>>> originating carrier, and is populated with the name obtained from >>>>>>> the billing and service data used to establish the service. The >>>>>>> database is queried by the terminating carrier with the phone >>>>>>> number to obtain the name. Recently, due to charges levied on >>>>>>> the terminating carrier by the originating carrier to query the >>>>>>> database, alternatives have arose where large consumer oriented >>>>>>> databases are queried that independently match name with >>>>>>> telephone number without reference to the originating carrier's >>>>>>> information. When the databases were operated by large >>>>>>> established telcos, the reliability of the data was good. >>>>>>> However, some service providers are now lax in how the data is >>>>>>> populated, and some even advertise the ability to allow any name >>>>>>> to be used with a number. This has significantly > erod >>>>>> ed >>>>>>> the usefulness of the service. Where caller name service is provided, it replaces the display of the calling party number, although smart phones will usually substitute their local contact list name for whatever is provided by the calling name service. This means that if stir succeeds in improving the quality of the calling party number, but no solution is provided for calling party name, fraudsters may still be able to disguise their activities. >>>>>>> >>>>>>> This work proposes to change how caller name is carried to using the existing display name portion of the SIP URI in the From or P-A-I field. The name would be carried in the signaling from origination to termination. This capability exists today, although the service providers typically do not restrict or asses what name the caller asserts. Therefore, along with the name would come a form of validation that the name is genuine, and, for calls from businesses, the type of business it is from. >>>>>>> >>>>>>> Validation of names is exceedingly difficult, and this work does >>>>>>> not propose a solution that will provide a name with absolute >>>>>>> certainty that it is genuine and associated with the telephone >>>>>>> number of the calling party. It does propose that the data be >>>>>>> vetted through some process, which may not result in a simple >>>>>>> "this is the name" result. Rather, the vetting process may >>>>>>> provide a name, but accompany it with a confidence factor(score) >>>>>>> indicating the source's assessment of the likelihood that the >>>>>>> name is represents the calling party. Confidence would be a >>>>>>> simple 0-100 scaler, without an attempt to precisely define or >>>>>>> normalize it between sources. That means that the termination >>>>>>> side would have to evaluate the confidence factor and the source >>>>>>> of the confidence together to decide how much to trust the name. >>>>>>> The termination could take a variety of actions based on the >>>>>>> source and the claimed confidence. Doing so implies that the >>>>>>> number of sources is limited so that eva > luati >>>>>> ng >>>>>>> the source for trustworthiness can be accomplished. >>>>>>> >>>>>>> Vetting the name at the source is more likely to be of value, because the source may have a variety of other information about the party the name is assigned to that can be used to improve the reliability of the vetting process. For example, address, other phone numbers, age, email addresses, domains (for businesses), etc can be used to provide much higher confidence that the name accurately represents the calling party than just the number known at the termination side. >>>>>>> >>>>>>> Besides the name, when a call is made from a business, the type of business can provide important information to the caller when deciding to answer the call, or trust the caller. The type of business would be a selection from an existing taxonomy of business types and would be relatively high level ("bank", "florist", "doctor"). >>>>>>> >>>>>>> The name, type of business (if appropriate), the source of the data, the confidence indicator and some indication of the vetting process would accompany the name in a new header in a secure manner -- secure in the sense that the number, the name, type, the source, and the sources' asserted confidence of the name is signed by the source. >>>>>>> >>>>>>> If the termination side did not trust the source, or it did, but the confidence was too low in its opinion, the termination may take a number of actions, including, but not limited to: >>>>>>> a) Refuse the call, or send it to voicemail >>>>>>> b) Use an independent source of names, like the alternative name >>>>>>> suppliers that exist today to display an alternate name >>>>>>> c) Provide a visual or audible warning to the user that the name >>>>>>> may not be valid >>>>>>> d) Provide a visual or audible representation of the confidence, >>>>>>> possibly simplified (red/orange/yellow/green) >>>>>>> e) Provide a caller feedback (thumbs up/down) mechanism to >>>>>>> further develop a rating of the source, or the specific >>>>>>> name/number pair >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: >>>>>>> >>>>>>>> I didn't want to get into solution space, but I'm a bit surprised by the question, since that's exactly what's been discussed, at length. The idea was that, unlike today, the textual callerID is generally traceable to the originating carrier and/or originating entity, for the Organization/From split I provided as an example earlier. >>>>>>>> >>>>>>>> As pointed out, that's not always true today, given that the destination has no clue which database is being used and who inserted the information there - a tier-1 carrier based on business records, listyourself.net based on caller assertion or some random white pages service based on who-knows. >>>>>>>> >>>>>>>> For the additional information, we have, as pointed out repeatedly, numerous third-party databases, both private and governmental. The originating carrier or possibly the originator can obtain and sign that information as a value-add. The ARID approach is another possibility. >>>>>>>> >>>>>>>> I've tried to provide very specific examples of how this could work, but am obviously not getting the point across. >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>>>>>> Sent: Monday, September 02, 2013 11:51 AM >>>>>>>> To: Henning Schulzrinne >>>>>>>> Cc: Stephen Farrell; cnit@ietf.org >>>>>>>> Subject: Re: [cnit] what's the actual problem here? >>>>>>>> >>>>>>>> >>>>>>>>> (b) indicate provenance of the information (e.g., was this >>>>>>>>> inserted by the caller, the caller's carrier or by the >>>>>>>>> receiving carrier, CNAM-style) >>>>>>>> >>>>>>>> I think that might be actually quite hard to accomplish, in a trustworthy manner. The terminating carrier would know whether it got the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where the LIDB data ultimately came from other than the LIDB AS for the calling number. >>>>>>>> >>>>>>>> Since the premise for this discussion is that calling names are not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their data be populated by untrustworthy sources. Is that correct? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -hadriel >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> >>>> >>> >>> >> > > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > From Henning.Schulzrinne@fcc.gov Wed Sep 4 15:34:04 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101FA21F9E51 for ; Wed, 4 Sep 2013 15:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bu3l51OW6oe for ; Wed, 4 Sep 2013 15:34:00 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id D324021F9DC6 for ; Wed, 4 Sep 2013 15:33:59 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Paul Kyzivat' Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgAGP9QCAAG6AkoABQEIAgAAhGoCAAAF1AIAABRgAgAACroCAAY5QAIAAA6sA///L1MCAAFu+gP//vXTQ Date: Wed, 4 Sep 2013 22:33:57 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52278EE6.1090400@alum.mit.edu> <5227B32B.1090905@alum.mit.edu> In-Reply-To: <5227B32B.1090905@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , 'Brian Rosen' Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 22:34:04 -0000 Having multiple sources signed works for me, but it does make the display n= ame mechanism harder to fit into the existing SIP model and adds complicati= ons to the UI. Also, I'm having a hard time thinking of cases where the callee provider ha= s better information than the call origin. This would only be the case if t= he caller somehow overrides the CNAM/LIDB information. For malicious caller= s that misrepresent themselves in the pick-your-own databases, this would o= bviously make no difference. There are legitimate reasons for the display name to differ from the billin= g name, e.g., for PBXs ("Jane Smith, working at GEICO"). This is why I earl= ier proposed that we use the two SIP headers available differently: the Org= anization field is signed by the originating carrier (or possibly the LIDB/= CNAM data by the terminating one) and the display name is signed by the num= ber holder. I suspect this only works if large providers allow this privile= ge only for customers they know and trust, i.e., larger business customers. -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Wednesday, September 04, 2013 6:25 PM To: Henning Schulzrinne Cc: cnit@ietf.org; 'Brian Rosen' Subject: Re: [cnit] what's the actual problem here? On 9/4/13 5:03 PM, Henning Schulzrinne wrote: > Today, we have two cases, neither of which has a satisfactory outcome: > > (1) Good original provider, bad (or cheap) callee provider: The injured p= arty is the business whose display is inaccurate or missing; they have no r= easonable way of fixing the problem. The callee likely believes that they s= ee information provided by the origin provider, and I suspect that, if they= had too much time on their hand and complain to their local service provid= er, the customer service rep would not know how callerID works and would be= happy to blame the caller. In most cases, they have no way of knowing whet= her the information is right, wrong or missing for a good reason. > > (2) Bad original data, good callee service provider: The callee service p= rovider can't do anything about the pick-your-own-text providers, as most o= f the data even for those services is probably still accurate, so they can'= t just drop those names. Again, no reasonable remedy. Based on Brian's comments, I was thinking that the callee service provider = would be making judgement calls on the trustworthiness of the original data= it is getting, and excluding that which it deems inadequate to meet the pr= omises it is making to its customers. Then if a customer complains that he isn't getting a name for certain calle= rs, the response (after checking the logs) can be that trustworthy name dat= a is not available for that caller. I'll grant that putting it in the hands of the callee provider has problems= for (1). But users of such providers likely have lots of problems. How about a mechanism that allows multiple signatures? Then both the origin= ating and terminating ends could sign. Then the callee looks for a signatur= e by somebody it knows/trusts. The callee provider will sign if it trusts t= he signature by the caller provider. Thanks, Paul > Thus, the current system seems pessimal - the entities that are incented = and knowledgeable can't fix problems. > > Henning > > -----Original Message----- > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, September 04, 2013 4:03 PM > To: Paul Kyzivat > Cc: cnit@ietf.org > Subject: Re: [cnit] what's the actual problem here? > > While I think the situation could be the same - your provider handles it = all, and you only see either "unknown" or a name, I think it will be more = probable that your device provider wants the data to make better use of it = than your provider could (since it's actions are more limited). You still = look to your provider (or device/app supplier). You don't look to the orig= ination provider. > > Brian > > On Sep 4, 2013, at 3:49 PM, Paul Kyzivat wrote: > >> Brian, >> >> My issue is with the trust model. Today this is a service offered by my = provider. If there are problems, I would complain to my provider. It may be= that my provider gets the data from a DB that was populated by the calling= provider, but that is not *my* problem. >> >> IIUC, in what you are proposing, the data I get will be signed by the ca= ller or calling provider. Then I must decide whether to trust that. And if = there are problems, then I presumably need to take it up with that provider= . >> >> Thanks, >> Paul >> >> On 9/3/13 4:04 PM, Brian Rosen wrote: >>> So you want to cut the originating provider, who has the most informati= on available to validate the number, completely out of the loop? >>> >>> We have this service now, and it's fairly good. Instead of paying the= origination provider for the LIDB dip, they pay us to dip out database wit= h the number. But because the only input to validation is phone number, wh= at comes out is variable quality. It also has a specific problem that new = service is very hard to accommodate. Until the number is in use within the= sources of data the database uses, the entry would be considered unknown. = That's not a huge problem to anyone but the new customer. >>> >>> So the objection I have to termination side DB dip is that the quality = of validation is constrained by the limited amount of information in the qu= ery. If I do validation on the origination, I get much better results. Th= at, by the way, is independent of any score that might be sent in the signa= ling. >>> >>> Brian >>> >>> >>> On Sep 3, 2013, at 3:54 PM, Paul Kyzivat wrote: >>> >>>> On 9/3/13 3:36 PM, Brian Rosen wrote: >>>>> Henning proposed to have some standardization of "method", but he mea= nt broad categories like "from billing records". That probably doesn't hel= p you, but I liked that idea. >>>>> >>>>> Without the validation, how would we change anything? As it exists n= ow, both the display name, if sent, and the content of the CNAM database ca= n easily be anything you want if you use a pink carrier. How would you pro= pose to fix that? >>>> >>>> As a user of this service, I would be more comfortable with it done by= an agent for the callee, based on number lookup. At least then the callee = has somebody to blame, and hopefully can choose which one. >>>> >>>> At least this way the callee has a contract with *somebody* that will = say *something* about the level of trust in the data, and a recourse if it = turns out to be wrong. >>>> >>>> I'm imagining that companies like Neustar would offer this service, ei= ther directly to the end user, or to the provider for the callee. And compa= nies like Google might also provide a service like this. The interface to t= he service need not be standardized. On smart phones you could install a ca= ll validation app that plugs into incoming call handling, and manages its o= wn display of the information. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Brian >>>>> >>>>> On Sep 3, 2013, at 3:31 PM, Paul Kyzivat wrot= e: >>>>> >>>>>> Nits: >>>>>> >>>>>> s/arose/arisen/ >>>>>> s/scaler/scalar/ >>>>>> >>>>>> Substance: >>>>>> >>>>>> I'm still not buying the trust chain that says: >>>>>> >>>>>> - caller supplies the name >>>>>> - caller's provider provides the validation of the name, using=20 >>>>>> an undefined method and scale >>>>>> - callee decides how to trust the name based on the provided=20 >>>>>> score and trust in the signer >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 9/3/13 1:32 PM, Brian Rosen wrote: >>>>>>> I'm going to try and restate the "what is the problem", working off= what has been said. >>>>>>> >>>>>>> In the PSTN today, there is an optional service that will=20 >>>>>>> display the name of the caller. The name is currently obtained=20 >>>>>>> from a database. Historically, the database is operated by the=20 >>>>>>> originating carrier, and is populated with the name obtained=20 >>>>>>> from the billing and service data used to establish the service. =20 >>>>>>> The database is queried by the terminating carrier with the=20 >>>>>>> phone number to obtain the name. Recently, due to charges=20 >>>>>>> levied on the terminating carrier by the originating carrier to=20 >>>>>>> query the database, alternatives have arose where large consumer=20 >>>>>>> oriented databases are queried that independently match name=20 >>>>>>> with telephone number without reference to the originating=20 >>>>>>> carrier's information. When the databases were operated by=20 >>>>>>> large established telcos, the reliability of the data was good. >>>>>>> However, some service providers are now lax in how the data is=20 >>>>>>> populated, and some even advertise the ability to allow any name=20 >>>>>>> to be used with a number. This has significantly > erod >>>>>> ed >>>>>>> the usefulness of the service. Where caller name service is pro= vided, it replaces the display of the calling party number, although smart = phones will usually substitute their local contact list name for whatever i= s provided by the calling name service. This means that if stir succeeds i= n improving the quality of the calling party number, but no solution is pro= vided for calling party name, fraudsters may still be able to disguise thei= r activities. >>>>>>> >>>>>>> This work proposes to change how caller name is carried to using th= e existing display name portion of the SIP URI in the From or P-A-I field. = The name would be carried in the signaling from origination to termination= . This capability exists today, although the service providers typically d= o not restrict or asses what name the caller asserts. Therefore, along wit= h the name would come a form of validation that the name is genuine, and, f= or calls from businesses, the type of business it is from. >>>>>>> >>>>>>> Validation of names is exceedingly difficult, and this work does=20 >>>>>>> not propose a solution that will provide a name with absolute=20 >>>>>>> certainty that it is genuine and associated with the telephone=20 >>>>>>> number of the calling party. It does propose that the data be=20 >>>>>>> vetted through some process, which may not result in a simple=20 >>>>>>> "this is the name" result. Rather, the vetting process may=20 >>>>>>> provide a name, but accompany it with a confidence factor(score)=20 >>>>>>> indicating the source's assessment of the likelihood that the=20 >>>>>>> name is represents the calling party. Confidence would be a=20 >>>>>>> simple 0-100 scaler, without an attempt to precisely define or=20 >>>>>>> normalize it between sources. That means that the termination=20 >>>>>>> side would have to evaluate the confidence factor and the source=20 >>>>>>> of the confidence together to decide how much to trust the name. >>>>>>> The termination could take a variety of actions based on the=20 >>>>>>> source and the claimed confidence. Doing so implies that the=20 >>>>>>> number of sources is limited so that eva > luati >>>>>> ng >>>>>>> the source for trustworthiness can be accomplished. >>>>>>> >>>>>>> Vetting the name at the source is more likely to be of value, becau= se the source may have a variety of other information about the party the n= ame is assigned to that can be used to improve the reliability of the vetti= ng process. For example, address, other phone numbers, age, email addresse= s, domains (for businesses), etc can be used to provide much higher confide= nce that the name accurately represents the calling party than just the num= ber known at the termination side. >>>>>>> >>>>>>> Besides the name, when a call is made from a business, the type of = business can provide important information to the caller when deciding to a= nswer the call, or trust the caller. The type of business would be a selec= tion from an existing taxonomy of business types and would be relatively hi= gh level ("bank", "florist", "doctor"). >>>>>>> >>>>>>> The name, type of business (if appropriate), the source of the data= , the confidence indicator and some indication of the vetting process would= accompany the name in a new header in a secure manner -- secure in the sen= se that the number, the name, type, the source, and the sources' asserted c= onfidence of the name is signed by the source. >>>>>>> >>>>>>> If the termination side did not trust the source, or it did, but th= e confidence was too low in its opinion, the termination may take a number = of actions, including, but not limited to: >>>>>>> a) Refuse the call, or send it to voicemail >>>>>>> b) Use an independent source of names, like the alternative name=20 >>>>>>> suppliers that exist today to display an alternate name >>>>>>> c) Provide a visual or audible warning to the user that the name=20 >>>>>>> may not be valid >>>>>>> d) Provide a visual or audible representation of the confidence,=20 >>>>>>> possibly simplified (red/orange/yellow/green) >>>>>>> e) Provide a caller feedback (thumbs up/down) mechanism to=20 >>>>>>> further develop a rating of the source, or the specific=20 >>>>>>> name/number pair >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: >>>>>>> >>>>>>>> I didn't want to get into solution space, but I'm a bit surprised = by the question, since that's exactly what's been discussed, at length. The= idea was that, unlike today, the textual callerID is generally traceable t= o the originating carrier and/or originating entity, for the Organization/F= rom split I provided as an example earlier. >>>>>>>> >>>>>>>> As pointed out, that's not always true today, given that the desti= nation has no clue which database is being used and who inserted the inform= ation there - a tier-1 carrier based on business records, listyourself.net = based on caller assertion or some random white pages service based on who-k= nows. >>>>>>>> >>>>>>>> For the additional information, we have, as pointed out repeatedly= , numerous third-party databases, both private and governmental. The origin= ating carrier or possibly the originator can obtain and sign that informati= on as a value-add. The ARID approach is another possibility. >>>>>>>> >>>>>>>> I've tried to provide very specific examples of how this could wor= k, but am obviously not getting the point across. >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>>>>>> Sent: Monday, September 02, 2013 11:51 AM >>>>>>>> To: Henning Schulzrinne >>>>>>>> Cc: Stephen Farrell; cnit@ietf.org >>>>>>>> Subject: Re: [cnit] what's the actual problem here? >>>>>>>> >>>>>>>> >>>>>>>>> (b) indicate provenance of the information (e.g., was this=20 >>>>>>>>> inserted by the caller, the caller's carrier or by the=20 >>>>>>>>> receiving carrier, CNAM-style) >>>>>>>> >>>>>>>> I think that might be actually quite hard to accomplish, in a trus= tworthy manner. The terminating carrier would know whether it got the name= from a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know w= here the LIDB data ultimately came from other than the LIDB AS for the call= ing number. >>>>>>>> >>>>>>>> Since the premise for this discussion is that calling names are no= t trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their da= ta be populated by untrustworthy sources. Is that correct? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -hadriel >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> >>>> >>> >>> >> > > _______________________________________________ > 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 From Henning.Schulzrinne@fcc.gov Wed Sep 4 15:41:48 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13D611E811E for ; Wed, 4 Sep 2013 15:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, MANGLED_ACTION=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7aaekvSURaO for ; Wed, 4 Sep 2013 15:41:42 -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 9DB5C21E8083 for ; Wed, 4 Sep 2013 15:41:40 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Cary FitzGerald' Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOppIsWQkKZQw+CEin5bQ6X8Hk+pmxTmxVgAGP9QCAAG6AkoABQEIAgAAhGoCAAAF1AIAABRgAgAACroCAAY5QAIAAA6sA///L1MCAAF13gP//vltQ Date: Wed, 4 Sep 2013 22:41:37 +0000 References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52278EE6.1090400@alum.mit.edu> <4240623D-480E-4968-BBB3-24AEB419EE6B@employees.org> In-Reply-To: <4240623D-480E-4968-BBB3-24AEB419EE6B@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , Paul Kyzivat , 'Brian Rosen' Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 22:41:48 -0000 I mainly care about clear responsibility so that all parties know who did w= hat (and maybe some meta-information about their source of the information)= and for new opportunities for "good" actors to provide such information. As you note, multiple reasonable models could emerge. This doesn't seem tha= t hard - as long as multiple parties, including the originator, originating= and terminating carrier, can add information and sign it, your objective w= ould seem to be met. It would be up to the carrier-customer contract as wel= l as national signaling integrity rules who can modify and delete informati= on (and clearly beyond any CNIT-related effort). -----Original Message----- From: Cary FitzGerald [mailto:caryfitz@gmail.com]=20 Sent: Wednesday, September 04, 2013 6:31 PM To: Henning Schulzrinne Cc: 'Brian Rosen'; Paul Kyzivat; cnit@ietf.org Subject: Re: [cnit] what's the actual problem here? Brian correctly says that the originating provider is the one who is most l= ikely to actually know who the originator is. Great. First, they are goin= g to assert that they know a number based on that relationship, and they us= e that number as the primary key into whatever database they have. If they= are good actors (like Hala describes), then the data they deliver will be = as accurate as their key(s) are into their database(s) modulo billing chang= es, etc. If they are bad actors, then, well, they are shoveling a bunch of= calls into the world and will be willing to do whatever is needed to termi= nate it. The originating service provider gets paid on the basis of how successful t= he originator is in terminating a call. The human terminating the call won= 't have a relationship with the originating service provider, and it's impr= actical to think that they will know any more than 1 or 2 out of the thousa= nds out there. The relationship they have with the originating SP is media= ted by their terminating SP. The terminating service provider gets paid based on completing the call, bu= t discounted on the costs in reputation (and presumably market share), cust= omer service and unwelcome regulatory oversight. It is much more reasonabl= e that the terminating SP should know something about the originating SPs. = Paul's saying=20 Organizations fill these roles: * The originating SP asserts that they have a call, that they have keys to = map the caller to a name, and that they want to launch this call into the n= etwork * Someone hosts a database that translates those keys into a name * Someone does the lookup of the keys in the database and asserts they know= a name with some confidence * Other someones rate how reliable the database and database dipper are, an= d/or offer other lookups * The terminating SP delivers the call in such a way that the human at the = end of the call can make a rational decision about how to make the call I don't think that the cnit architecture/protocol should say who the someon= es are; the architecture should allow for a diversity of answers. Regulato= rs and the market need to have the flexibility to shape who does what for w= hom at what cost/value. I'm sympathetic to Henning's hope that something like the reliability of ca= lling name delivery can be restored to status quo ante bellum. I can see h= ow the architecture can make that easier or harder to do, but given that pa= rt of the end service is based on the intention/motives of the players, the= best thing that this group can do is to create an architecture that allows= for external forces to act ion the players in rational ways. From caryfitz@gmail.com Wed Sep 4 15:59:41 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C372121E8051 for ; Wed, 4 Sep 2013 15:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MANGLED_ACTION=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9ARxRJVvV79 for ; Wed, 4 Sep 2013 15:59:40 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 555C121F941F for ; Wed, 4 Sep 2013 15:59:40 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id u16so2063560iet.6 for ; Wed, 04 Sep 2013 15:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9rFi5Cu4pyRT5mdgOLE/8WQRqQzAGH66O3rQps/O2mM=; b=FGckUwTwCWkQZfh1XYR7j03p+v9jSJ8p5WfmlsAtz3UrUgYcydJNCXfQGEejcSq3v1 PWM6Xr+18axbUBaZwyvAgclNH0MQF+mPjskSBWCwOdfc7GJvep3BAyHO7Pe3m9dajJYV dkbtJxGZW45Rir+foHbzsR56+czAsHb9FXtPhdFPJRsCVNarMY+rXc/iIikEG3umNunA 8BWUaaMNaiLXAwKYMuVOEKYk2JoVytRrXMuL35afBoxIEdRHMY70XcUS9LmoA6iyDxeP TCvAQcQ/jehUKRGmfS7EQRQ9BzdshyjYvx0SncuY/eXEoj+BLaJbR6kTZxqKrozmGeHs +aqQ== X-Received: by 10.50.61.241 with SMTP id t17mr3767488igr.28.1378335578646; Wed, 04 Sep 2013 15:59:38 -0700 (PDT) Received: from [192.168.1.115] ([72.169.166.149]) by mx.google.com with ESMTPSA id i11sm6478376igh.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 15:59:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Cary FitzGerald In-Reply-To: Date: Wed, 4 Sep 2013 15:59:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A8A4CD7-6BD7-4445-9280-D9DB61D4B211@employees.org> References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52278EE6.1090400@alum.mit.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Wed, 04 Sep 2013 17:28:24 -0700 Cc: "cnit@ietf.org" , Paul Kyzivat , 'Brian Rosen' Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 23:00:41 -0000 Brian correctly says that the originating provider is the one who is = most likely to actually know who the originator is. Great. First, they = are going to assert that they know a number based on that relationship, = and they use that number as the primary key into whatever database they = have. If they are good actors (like Hala describes), then the data they = deliver will be as accurate as their key(s) are into their database(s) = modulo billing changes, etc. If they are bad actors, then, well, they = are shoveling a bunch of calls into the world and will be willing to do = whatever is needed to terminate it. The originating service provider gets paid on the basis of how = successful the originator is in terminating a call. The human = terminating the call won't have a relationship with the originating = service provider, and it's impractical to think that they will know any = more than 1 or 2 out of the thousands out there. The relationship they = have with the originating SP is mediated by their terminating SP. The terminating service provider gets paid based on completing the call, = but discounted on the costs in reputation (and presumably market share), = customer service and unwelcome regulatory oversight. It is much more = reasonable that the terminating SP should know something about the = originating SPs. Paul's saying=20 Organizations fill these roles: * The originating SP asserts that they have a call, that they have keys = to map the caller to a name, and that they want to launch this call into = the network * Someone hosts a database that translates those keys into a name * Someone does the lookup of the keys in the database and asserts they = know a name with some confidence * Other someones rate how reliable the database and database dipper are, = and/or offer other lookups * The terminating SP delivers the call in such a way that the human at = the end of the call can make a rational decision about how to make the = call I don't think that the cnit architecture/protocol should say who the = someones are; the architecture should allow for a diversity of answers. = Regulators and the market need to have the flexibility to shape who does = what for whom at what cost/value. I'm sympathetic to Henning's hope that something like the reliability of = calling name delivery can be restored to status quo ante bellum. I can = see how the architecture can make that easier or harder to do, but given = that part of the end service is based on the intention/motives of the = players, the best thing that this group can do is to create an = architecture that allows for external forces to act ion the players in = rational ways. * On Sep 4, 2013, at 2:03 PM, Henning Schulzrinne wrote: > Today, we have two cases, neither of which has a satisfactory outcome: >=20 > (1) Good original provider, bad (or cheap) callee provider: The = injured party is the business whose display is inaccurate or missing; = they have no reasonable way of fixing the problem. The callee likely = believes that they see information provided by the origin provider, and = I suspect that, if they had too much time on their hand and complain to = their local service provider, the customer service rep would not know = how callerID works and would be happy to blame the caller. In most = cases, they have no way of knowing whether the information is right, = wrong or missing for a good reason. >=20 > (2) Bad original data, good callee service provider: The callee = service provider can't do anything about the pick-your-own-text = providers, as most of the data even for those services is probably still = accurate, so they can't just drop those names. Again, no reasonable = remedy. >=20 > Thus, the current system seems pessimal - the entities that are = incented and knowledgeable can't fix problems.=20 >=20 > Henning >=20 > -----Original Message----- > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Wednesday, September 04, 2013 4:03 PM > To: Paul Kyzivat > Cc: cnit@ietf.org > Subject: Re: [cnit] what's the actual problem here? >=20 > While I think the situation could be the same - your provider handles = it all, and you only see either "unknown" or a name, I think it will be = more probable that your device provider wants the data to make better = use of it than your provider could (since it's actions are more = limited). You still look to your provider (or device/app supplier). = You don't look to the origination provider. >=20 > Brian >=20 > On Sep 4, 2013, at 3:49 PM, Paul Kyzivat = wrote: >=20 >> Brian, >>=20 >> My issue is with the trust model. Today this is a service offered by = my provider. If there are problems, I would complain to my provider. It = may be that my provider gets the data from a DB that was populated by = the calling provider, but that is not *my* problem. >>=20 >> IIUC, in what you are proposing, the data I get will be signed by the = caller or calling provider. Then I must decide whether to trust that. = And if there are problems, then I presumably need to take it up with = that provider. >>=20 >> Thanks, >> Paul >>=20 >> On 9/3/13 4:04 PM, Brian Rosen wrote: >>> So you want to cut the originating provider, who has the most = information available to validate the number, completely out of the = loop? >>>=20 >>> We have this service now, and it's fairly good. Instead of paying = the origination provider for the LIDB dip, they pay us to dip out = database with the number. But because the only input to validation is = phone number, what comes out is variable quality. It also has a = specific problem that new service is very hard to accommodate. Until = the number is in use within the sources of data the database uses, the = entry would be considered unknown. That's not a huge problem to anyone = but the new customer. >>>=20 >>> So the objection I have to termination side DB dip is that the = quality of validation is constrained by the limited amount of = information in the query. If I do validation on the origination, I get = much better results. That, by the way, is independent of any score that = might be sent in the signaling. >>>=20 >>> Brian >>>=20 >>>=20 >>> On Sep 3, 2013, at 3:54 PM, Paul Kyzivat = wrote: >>>=20 >>>> On 9/3/13 3:36 PM, Brian Rosen wrote: >>>>> Henning proposed to have some standardization of "method", but he = meant broad categories like "from billing records". That probably = doesn't help you, but I liked that idea. >>>>>=20 >>>>> Without the validation, how would we change anything? As it = exists now, both the display name, if sent, and the content of the CNAM = database can easily be anything you want if you use a pink carrier. How = would you propose to fix that? >>>>=20 >>>> As a user of this service, I would be more comfortable with it done = by an agent for the callee, based on number lookup. At least then the = callee has somebody to blame, and hopefully can choose which one. >>>>=20 >>>> At least this way the callee has a contract with *somebody* that = will say *something* about the level of trust in the data, and a = recourse if it turns out to be wrong. >>>>=20 >>>> I'm imagining that companies like Neustar would offer this service, = either directly to the end user, or to the provider for the callee. And = companies like Google might also provide a service like this. The = interface to the service need not be standardized. On smart phones you = could install a call validation app that plugs into incoming call = handling, and manages its own display of the information. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>> Brian >>>>>=20 >>>>> On Sep 3, 2013, at 3:31 PM, Paul Kyzivat = wrote: >>>>>=20 >>>>>> Nits: >>>>>>=20 >>>>>> s/arose/arisen/ >>>>>> s/scaler/scalar/ >>>>>>=20 >>>>>> Substance: >>>>>>=20 >>>>>> I'm still not buying the trust chain that says: >>>>>>=20 >>>>>> - caller supplies the name >>>>>> - caller's provider provides the validation of the name, using = an=20 >>>>>> undefined method and scale >>>>>> - callee decides how to trust the name based on the provided=20 >>>>>> score and trust in the signer >>>>>>=20 >>>>>> Thanks, >>>>>> Paul >>>>>>=20 >>>>>> On 9/3/13 1:32 PM, Brian Rosen wrote: >>>>>>> I'm going to try and restate the "what is the problem", working = off what has been said. >>>>>>>=20 >>>>>>> In the PSTN today, there is an optional service that will = display=20 >>>>>>> the name of the caller. The name is currently obtained from a=20= >>>>>>> database. Historically, the database is operated by the=20 >>>>>>> originating carrier, and is populated with the name obtained = from=20 >>>>>>> the billing and service data used to establish the service. The=20= >>>>>>> database is queried by the terminating carrier with the phone=20 >>>>>>> number to obtain the name. Recently, due to charges levied on=20= >>>>>>> the terminating carrier by the originating carrier to query the=20= >>>>>>> database, alternatives have arose where large consumer oriented=20= >>>>>>> databases are queried that independently match name with=20 >>>>>>> telephone number without reference to the originating carrier's=20= >>>>>>> information. When the databases were operated by large=20 >>>>>>> established telcos, the reliability of the data was good. =20 >>>>>>> However, some service providers are now lax in how the data is=20= >>>>>>> populated, and some even advertise the ability to allow any name=20= >>>>>>> to be used with a number. This has significantly > erod >>>>>> ed >>>>>>> the usefulness of the service. Where caller name service is = provided, it replaces the display of the calling party number, although = smart phones will usually substitute their local contact list name for = whatever is provided by the calling name service. This means that if = stir succeeds in improving the quality of the calling party number, but = no solution is provided for calling party name, fraudsters may still be = able to disguise their activities. >>>>>>>=20 >>>>>>> This work proposes to change how caller name is carried to using = the existing display name portion of the SIP URI in the =46rom or P-A-I = field. The name would be carried in the signaling from origination to = termination. This capability exists today, although the service = providers typically do not restrict or asses what name the caller = asserts. Therefore, along with the name would come a form of validation = that the name is genuine, and, for calls from businesses, the type of = business it is from. >>>>>>>=20 >>>>>>> Validation of names is exceedingly difficult, and this work does=20= >>>>>>> not propose a solution that will provide a name with absolute=20 >>>>>>> certainty that it is genuine and associated with the telephone=20= >>>>>>> number of the calling party. It does propose that the data be=20= >>>>>>> vetted through some process, which may not result in a simple=20 >>>>>>> "this is the name" result. Rather, the vetting process may=20 >>>>>>> provide a name, but accompany it with a confidence factor(score)=20= >>>>>>> indicating the source's assessment of the likelihood that the=20 >>>>>>> name is represents the calling party. Confidence would be a=20 >>>>>>> simple 0-100 scaler, without an attempt to precisely define or=20= >>>>>>> normalize it between sources. That means that the termination=20= >>>>>>> side would have to evaluate the confidence factor and the source=20= >>>>>>> of the confidence together to decide how much to trust the name. = =20 >>>>>>> The termination could take a variety of actions based on the=20 >>>>>>> source and the claimed confidence. Doing so implies that the=20 >>>>>>> number of sources is limited so that eva > luati >>>>>> ng >>>>>>> the source for trustworthiness can be accomplished. >>>>>>>=20 >>>>>>> Vetting the name at the source is more likely to be of value, = because the source may have a variety of other information about the = party the name is assigned to that can be used to improve the = reliability of the vetting process. For example, address, other phone = numbers, age, email addresses, domains (for businesses), etc can be used = to provide much higher confidence that the name accurately represents = the calling party than just the number known at the termination side. >>>>>>>=20 >>>>>>> Besides the name, when a call is made from a business, the type = of business can provide important information to the caller when = deciding to answer the call, or trust the caller. The type of business = would be a selection from an existing taxonomy of business types and = would be relatively high level ("bank", "florist", "doctor"). >>>>>>>=20 >>>>>>> The name, type of business (if appropriate), the source of the = data, the confidence indicator and some indication of the vetting = process would accompany the name in a new header in a secure manner -- = secure in the sense that the number, the name, type, the source, and the = sources' asserted confidence of the name is signed by the source. >>>>>>>=20 >>>>>>> If the termination side did not trust the source, or it did, but = the confidence was too low in its opinion, the termination may take a = number of actions, including, but not limited to: >>>>>>> a) Refuse the call, or send it to voicemail >>>>>>> b) Use an independent source of names, like the alternative name=20= >>>>>>> suppliers that exist today to display an alternate name >>>>>>> c) Provide a visual or audible warning to the user that the name=20= >>>>>>> may not be valid >>>>>>> d) Provide a visual or audible representation of the confidence,=20= >>>>>>> possibly simplified (red/orange/yellow/green) >>>>>>> e) Provide a caller feedback (thumbs up/down) mechanism to=20 >>>>>>> further develop a rating of the source, or the specific=20 >>>>>>> name/number pair >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne = wrote: >>>>>>>=20 >>>>>>>> I didn't want to get into solution space, but I'm a bit = surprised by the question, since that's exactly what's been discussed, = at length. The idea was that, unlike today, the textual callerID is = generally traceable to the originating carrier and/or originating = entity, for the Organization/=46rom split I provided as an example = earlier. >>>>>>>>=20 >>>>>>>> As pointed out, that's not always true today, given that the = destination has no clue which database is being used and who inserted = the information there - a tier-1 carrier based on business records, = listyourself.net based on caller assertion or some random white pages = service based on who-knows. >>>>>>>>=20 >>>>>>>> For the additional information, we have, as pointed out = repeatedly, numerous third-party databases, both private and = governmental. The originating carrier or possibly the originator can = obtain and sign that information as a value-add. The ARID approach is = another possibility. >>>>>>>>=20 >>>>>>>> I've tried to provide very specific examples of how this could = work, but am obviously not getting the point across. >>>>>>>>=20 >>>>>>>> ________________________________________ >>>>>>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>>>>>> Sent: Monday, September 02, 2013 11:51 AM >>>>>>>> To: Henning Schulzrinne >>>>>>>> Cc: Stephen Farrell; cnit@ietf.org >>>>>>>> Subject: Re: [cnit] what's the actual problem here? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> (b) indicate provenance of the information (e.g., was this=20 >>>>>>>>> inserted by the caller, the caller's carrier or by the=20 >>>>>>>>> receiving carrier, CNAM-style) >>>>>>>>=20 >>>>>>>> I think that might be actually quite hard to accomplish, in a = trustworthy manner. The terminating carrier would know whether it got = the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it = doesn't know where the LIDB data ultimately came from other than the = LIDB AS for the calling number. >>>>>>>>=20 >>>>>>>> Since the premise for this discussion is that calling names are = not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting = their data be populated by untrustworthy sources. Is that correct? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -hadriel >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> cnit mailing list >>>>>>>> cnit@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> cnit mailing list >>>>>>> cnit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> cnit mailing list >>>>>> cnit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cnit >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > 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 From hala.mowafy@ericsson.com Wed Sep 4 20:03:36 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A8C11E824B for ; Wed, 4 Sep 2013 20:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.154 X-Spam-Level: X-Spam-Status: No, score=-1.154 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI1PApipMPaQ for ; Wed, 4 Sep 2013 20:03:31 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7648011E8204 for ; Wed, 4 Sep 2013 20:03:31 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-a6-5227f482e4c4 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F2.6B.09414.284F7225; Thu, 5 Sep 2013 05:03:30 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Wed, 4 Sep 2013 23:03:30 -0400 From: Hala Mowafy To: Hadriel Kaplan Thread-Topic: [cnit] what's the actual problem here? Thread-Index: AQHOpo/ihSvGsOHCgUiEYFTUCt4llpmxlP0AgAFJaQCAALUCgIACc1wAgAABa7CAAF7JgIAAB7UA Date: Thu, 5 Sep 2013 03:03:28 +0000 Message-ID: <728F35AE98AEDB4A96FF3A32A85A60BB117F0CE9@eusaamb105.ericsson.se> References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <728F35AE98AEDB4A96FF3A32A85A60BB117F0909@eusaamb105.ericsson.se> <809B16BC-EDB5-473A-B6AE-E7299797182C@oracle.com> In-Reply-To: <809B16BC-EDB5-473A-B6AE-E7299797182C@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXSPt27TF/Ugg13T1Cyuzt7HaPFp0ydm i59HdrNaTN97jd2BxWNt91U2j9u337B5LFnyk8nj49NbLAEsUVw2Kak5mWWpRfp2CVwZn7ae YS3oda+YsTitgfGGZRcjJ4eEgInE80mnmSFsMYkL99azgdhCAkcZJebM8upi5AKylzFKvPh2 igkkwSagIzHn70egBg4OEQE9iaP3OEFqmAVaGSXOf5nFDlIjLGAscfraU7BBIkALTh5ewgpR HyVxbz03SJhFQEXi/4NjrCA2r4CvxLKvi9ghdn1mknh1YBoLSIJTwE6i6cgksL2MQMd9P7UG zGYWEJe49WQ+E8TRAhJL9pyHekBU4uXjf6wQtrLE9zmPWCDqdSQW7P7EBmFrSyxb+JoZYrGg xMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw33chgEyMwlo5JsOnuYNzz0vIQozQH i5I47yq9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGH0UH4eFCjk3nP00bfGeuayBf36/ rSuZvCqcgX9Bhd+5cz84jQ/X6lkulD92Z8WE0OpfMzT/3845+uX9jMcZqqvEgn7r/1XdujPB ZALLJK+HV2pSVtqHXxH+ukKXYWLe3Wa+UOOU0H+npN1l3XXlWp4Hdcl7da0MXXTcIpbB6nx8 yOm8D/tvCiuxFGckGmoxFxUnAgAYFzQbcwIAAA== Cc: "cnit@ietf.org" , Stephen Farrell , Henning Schulzrinne Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 03:03:36 -0000 Hi Hadriel,=20 Correct! Not countering your points; rather adding to them. I expanded simply to correct the misconceptions I keep reading in the threa= d about LIDB - to everyone in one shot. =20 Hala =20 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Wednesday, September 04, 2013 5:49 PM To: Hala Mowafy Cc: Henning Schulzrinne; cnit@ietf.org; Stephen Farrell Subject: Re: [cnit] what's the actual problem here? Hi Hala, I'm not sure if you meant those points as countering mine, but I think they= 're consistent with what I was saying. No? -hadriel On Sep 4, 2013, at 4:44 PM, Hala Mowafy wrote: > Hadriel, >=20 > I worked on LIDB's architecture and services for a number of years and I'= d like to offer a few points of clarification: > - When talking about a LIDB operated by the traditional carriers in the U= .S. (e.g., AT&T) the data stored in LIDB is derived from the service order = and the direct relationship the carrier has with each customer - not from m= ailing lists or credit bureaus. Third party databases - because in most ca= ses they have no direct relation with the end user - tend to use a variety = of marketing sources, as such. I cannot speak of TARGUSinfo (now Neustar) = or any other entrepreneur out there that created a database from the white = pages but later on failed to update the records in a timely fashion. Some = are better than others, of course. > - However, it is worth noting that in my 10 years on LIDB, whenever our t= eam received field trouble reports on CNAM (customers complaining about rec= eiving incorrect names, names of people long dead, etc.) the result of the = investigations pointed to third party databases containing aged data - more= than 95% of the time. No exaggeration! > - The role of the LIDB Administration System (AS) - as Ken pointed out - = is to maintain the master files (if you will) and provision the LIDB line r= ecords. The AS also updates LIDB any time a change occurs with the account= , again based on any changes the customer makes in his/her service profile.= The AS periodically audits LIDB line records against the customers' billi= ng records to ensure no data entry/human errors occurred, etc. The LIDB ad= ministrators go to great lengths to maintain the integrity and accuracy of = the data in LIDB and do not simply accept variations of the name on a whim. > - To your question: The AO or account owner is a data parameter on each = LIDB line record that contains the SPID or service provider ID responsible = for that account. =20 > - When you mentioned "validation service" I chuckled because there is a c= ompletely different service that LIDB offers called "Validation Service" bu= t it is not what CNIT or STIR is thinking of (certifications and all). Ins= tead it is a validation of customer data (name, billing address, phone numb= er, preferred language, ZIP Code, and more) that some retailers and banks h= ave started using to help reduce their online retail fraud. In the area of= Validation Service, LIDB sometimes competes with and sometimes complements= a large number of other data sources that retailers use. From working wit= h members of the Merchant Risk Council (MRC) for over 3 years, the feedback= I got was that they received better accuracy ratings when they trialed LID= B than they did with other sources for various sets of data. =20 > - I really don't like talking about pricing models in this venue because = business decisions should drive that. However, given that my company does= not own a LIDB, I feel a little better offering this observation from my i= ndustry interactions regarding LIDB's pricing model:- Most people are stil= l under the impression that LIDB query prices are exorbitant (a few pennies= per query back in the 1980s) when indeed it is a fraction of a U.S. penny = for CNAM and the Validation Services today. =20 >=20 > Hala >=20 > -----Original Message----- > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of H= adriel Kaplan > Sent: Wednesday, September 04, 2013 12:04 PM > To: Henning Schulzrinne > Cc: cnit@ietf.org; Stephen Farrell > Subject: Re: [cnit] what's the actual problem here? >=20 >=20 > I asked the question because it seems to me there's a contradiction in he= re somewhere. >=20 > From a 10k foot view, the current LIDB model is essentially the model bei= ng proposed as the solution. Not the pricing model, maybe, but the archite= ctural model. >=20 > The model being proposed is "the originator uses a name validation servic= e that provides some assertion about the originating text name, and everyon= e else trusts that validation service's assertion". That sure sounds like = LIDB to me, just with different powerpoint slide icons. The LIDB AS runs t= he database for its phone number customers, and in theory the AS should aud= it/verify the contents of its name entries to be valid. It also provides a= lot more than simply calling name data today, and if we think it needs eve= n more information then we can talk about that. >=20 > But if bad names are entering the LIDB databases, then I don't know why w= e think they won't enter whatever "validation service" we're talking about.= Sure they might not enter TARGUSinfo databases, but there's no reason to = think everyone will start using TARGUSinfo for their validation service. F= or example why wouldn't the existing LIDB AS providers simply market themse= lves as a "validation service" to their existing customers? And since some= Tier-1 carriers run their own LIDB AS, why would they switch to someone el= se? >=20 > If the answer to that is "well no one would trust claimed names from LIDB= AS", I find that hard to believe, since they appear to be trusted sufficie= ntly right now; and it's not in the power of the terminating carriers to fo= rce the originating carriers to use a different LIDB AS. >=20 > Ultimately if this whole thing just boils down to "we don't know how this= name got into the DB", then add a field to LIDB identifying the source... = if an existing field doesn't already do that. (what does the "Account Owner= " field hold?) >=20 > The other "problem" I've heard about LIDB is the pricing model, but that'= s a separate issue. >=20 > -hadriel >=20 >=20 > On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: >=20 >> I didn't want to get into solution space, but I'm a bit surprised by the= question, since that's exactly what's been discussed, at length. The idea = was that, unlike today, the textual callerID is generally traceable to the = originating carrier and/or originating entity, for the Organization/From sp= lit I provided as an example earlier. >>=20 >> As pointed out, that's not always true today, given that the destination= has no clue which database is being used and who inserted the information = there - a tier-1 carrier based on business records, listyourself.net based = on caller assertion or some random white pages service based on who-knows. >>=20 >> For the additional information, we have, as pointed out repeatedly, nume= rous third-party databases, both private and governmental. The originating = carrier or possibly the originator can obtain and sign that information as = a value-add. The ARID approach is another possibility. >>=20 >> I've tried to provide very specific examples of how this could work, but= am obviously not getting the point across. >>=20 >> ________________________________________ >> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >> Sent: Monday, September 02, 2013 11:51 AM >> To: Henning Schulzrinne >> Cc: Stephen Farrell; cnit@ietf.org >> Subject: Re: [cnit] what's the actual problem here? >>=20 >>=20 >>> (b) indicate provenance of the information (e.g., was this inserted by = the caller, the caller's carrier or by the receiving carrier, CNAM-style) >>=20 >> I think that might be actually quite hard to accomplish, in a trustworth= y manner. The terminating carrier would know whether it got the name from = a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where t= he LIDB data ultimately came from other than the LIDB AS for the calling nu= mber. >>=20 >> Since the premise for this discussion is that calling names are not trus= tworthy anymore (?), I'm assuming the LIDB AS'es are letting their data be = populated by untrustworthy sources. Is that correct? >>=20 >>=20 >>=20 >> -hadriel >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 > _______________________________________________ > 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 From pkyzivat@alum.mit.edu Wed Sep 4 22:00:16 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598E421E805D for ; Wed, 4 Sep 2013 22:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkTt7LN9x4ux for ; Wed, 4 Sep 2013 22:00:11 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id D8A8D21F84A5 for ; Wed, 4 Sep 2013 22:00:10 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta08.westchester.pa.mail.comcast.net with comcast id MGyX1m0021ap0As58H09ez; Thu, 05 Sep 2013 05:00:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id MH071m00p3ZTu2S3iH08nJ; Thu, 05 Sep 2013 05:00:09 +0000 Message-ID: <52280FD7.80708@alum.mit.edu> Date: Thu, 05 Sep 2013 01:00:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52278EE6.1090400@alum.mit.edu> <5227B32B.1090905@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378357209; bh=v5ixxdzrgb7MgQ3UaFxXPj3kpOwIepdnQgtSgqoCBYo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LQJ6jzgIAVYmrGUvlDyF4Nw4DdDfrojaMMhEMUn64Izl/jPj/gE8uWUEr8D8FRyX7 P6lLgX8Kd/hR+hLmPYDOEuX202kx3Hs6QQMMal4cZUzxgjmFR7Dz2yNV5VbVf8mv9G R4lZGYqThi1V2JghylkSbAvNUteKcynAswdozeCQI6nsoe4zyDU87TiByedQCOG7I/ ZFLdKRebGQ1vC1pKMF3zPoiCq+azuryK6p1SsvCqpfMjMuOBWlJ7Dm6Sdk7fPaWTmO cKymenJjljKX1BsEa/naJdqDWc1+Xp/6vM/noO+/7O+TOop1UUpfN07E8aqhufVuTs OjrRtdsiTaP5Q== Cc: "cnit@ietf.org" , 'Brian Rosen' Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 05:00:17 -0000 On 9/4/13 6:33 PM, Henning Schulzrinne wrote: > Having multiple sources signed works for me, but it does make the display name mechanism harder to fit into the existing SIP model and adds complications to the UI. > > Also, I'm having a hard time thinking of cases where the callee provider has better information than the call origin. This would only be the case if the caller somehow overrides the CNAM/LIDB information. For malicious callers that misrepresent themselves in the pick-your-own databases, this would obviously make no difference. My point wasn't that the callee provider has better (or even different) information than the calling provider. My point is that the callee provider is the one the callee knows. He depends on his provider to screen the information from caller providers, and indicate that it has done so by signing again. E.g., Caller says he is John Doe. Caller provider Alpha signs that. Callee provider Beta checks the signature, and its own rating of provider Alpha, and signs with its key. The callee can then check either or both signatures. If he only knows Beta, then he only checks for that signature and otherwise treats as unsigned. Another, more complex, callee might have a number of signers it trusts. Really simple callees simply check P-Asserted-ID, and trust their provider to only put trusted stuff in there. Thanks, Paul > There are legitimate reasons for the display name to differ from the billing name, e.g., for PBXs ("Jane Smith, working at GEICO"). This is why I earlier proposed that we use the two SIP headers available differently: the Organization field is signed by the originating carrier (or possibly the LIDB/CNAM data by the terminating one) and the display name is signed by the number holder. I suspect this only works if large providers allow this privilege only for customers they know and trust, i.e., larger business customers. > > -----Original Message----- > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, September 04, 2013 6:25 PM > To: Henning Schulzrinne > Cc: cnit@ietf.org; 'Brian Rosen' > Subject: Re: [cnit] what's the actual problem here? > > On 9/4/13 5:03 PM, Henning Schulzrinne wrote: >> Today, we have two cases, neither of which has a satisfactory outcome: >> >> (1) Good original provider, bad (or cheap) callee provider: The injured party is the business whose display is inaccurate or missing; they have no reasonable way of fixing the problem. The callee likely believes that they see information provided by the origin provider, and I suspect that, if they had too much time on their hand and complain to their local service provider, the customer service rep would not know how callerID works and would be happy to blame the caller. In most cases, they have no way of knowing whether the information is right, wrong or missing for a good reason. >> >> (2) Bad original data, good callee service provider: The callee service provider can't do anything about the pick-your-own-text providers, as most of the data even for those services is probably still accurate, so they can't just drop those names. Again, no reasonable remedy. > > Based on Brian's comments, I was thinking that the callee service provider would be making judgement calls on the trustworthiness of the original data it is getting, and excluding that which it deems inadequate to meet the promises it is making to its customers. > > Then if a customer complains that he isn't getting a name for certain callers, the response (after checking the logs) can be that trustworthy name data is not available for that caller. > > I'll grant that putting it in the hands of the callee provider has problems for (1). But users of such providers likely have lots of problems. > > How about a mechanism that allows multiple signatures? Then both the originating and terminating ends could sign. Then the callee looks for a signature by somebody it knows/trusts. The callee provider will sign if it trusts the signature by the caller provider. > > Thanks, > Paul > >> Thus, the current system seems pessimal - the entities that are incented and knowledgeable can't fix problems. >> >> Henning >> >> -----Original Message----- >> From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf >> Of Brian Rosen >> Sent: Wednesday, September 04, 2013 4:03 PM >> To: Paul Kyzivat >> Cc: cnit@ietf.org >> Subject: Re: [cnit] what's the actual problem here? >> >> While I think the situation could be the same - your provider handles it all, and you only see either "unknown" or a name, I think it will be more probable that your device provider wants the data to make better use of it than your provider could (since it's actions are more limited). You still look to your provider (or device/app supplier). You don't look to the origination provider. >> >> Brian >> >> On Sep 4, 2013, at 3:49 PM, Paul Kyzivat wrote: >> >>> Brian, >>> >>> My issue is with the trust model. Today this is a service offered by my provider. If there are problems, I would complain to my provider. It may be that my provider gets the data from a DB that was populated by the calling provider, but that is not *my* problem. >>> >>> IIUC, in what you are proposing, the data I get will be signed by the caller or calling provider. Then I must decide whether to trust that. And if there are problems, then I presumably need to take it up with that provider. >>> >>> Thanks, >>> Paul >>> >>> On 9/3/13 4:04 PM, Brian Rosen wrote: >>>> So you want to cut the originating provider, who has the most information available to validate the number, completely out of the loop? >>>> >>>> We have this service now, and it's fairly good. Instead of paying the origination provider for the LIDB dip, they pay us to dip out database with the number. But because the only input to validation is phone number, what comes out is variable quality. It also has a specific problem that new service is very hard to accommodate. Until the number is in use within the sources of data the database uses, the entry would be considered unknown. That's not a huge problem to anyone but the new customer. >>>> >>>> So the objection I have to termination side DB dip is that the quality of validation is constrained by the limited amount of information in the query. If I do validation on the origination, I get much better results. That, by the way, is independent of any score that might be sent in the signaling. >>>> >>>> Brian >>>> >>>> >>>> On Sep 3, 2013, at 3:54 PM, Paul Kyzivat wrote: >>>> >>>>> On 9/3/13 3:36 PM, Brian Rosen wrote: >>>>>> Henning proposed to have some standardization of "method", but he meant broad categories like "from billing records". That probably doesn't help you, but I liked that idea. >>>>>> >>>>>> Without the validation, how would we change anything? As it exists now, both the display name, if sent, and the content of the CNAM database can easily be anything you want if you use a pink carrier. How would you propose to fix that? >>>>> >>>>> As a user of this service, I would be more comfortable with it done by an agent for the callee, based on number lookup. At least then the callee has somebody to blame, and hopefully can choose which one. >>>>> >>>>> At least this way the callee has a contract with *somebody* that will say *something* about the level of trust in the data, and a recourse if it turns out to be wrong. >>>>> >>>>> I'm imagining that companies like Neustar would offer this service, either directly to the end user, or to the provider for the callee. And companies like Google might also provide a service like this. The interface to the service need not be standardized. On smart phones you could install a call validation app that plugs into incoming call handling, and manages its own display of the information. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Brian >>>>>> >>>>>> On Sep 3, 2013, at 3:31 PM, Paul Kyzivat wrote: >>>>>> >>>>>>> Nits: >>>>>>> >>>>>>> s/arose/arisen/ >>>>>>> s/scaler/scalar/ >>>>>>> >>>>>>> Substance: >>>>>>> >>>>>>> I'm still not buying the trust chain that says: >>>>>>> >>>>>>> - caller supplies the name >>>>>>> - caller's provider provides the validation of the name, using >>>>>>> an undefined method and scale >>>>>>> - callee decides how to trust the name based on the provided >>>>>>> score and trust in the signer >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> On 9/3/13 1:32 PM, Brian Rosen wrote: >>>>>>>> I'm going to try and restate the "what is the problem", working off what has been said. >>>>>>>> >>>>>>>> In the PSTN today, there is an optional service that will >>>>>>>> display the name of the caller. The name is currently obtained >>>>>>>> from a database. Historically, the database is operated by the >>>>>>>> originating carrier, and is populated with the name obtained >>>>>>>> from the billing and service data used to establish the service. >>>>>>>> The database is queried by the terminating carrier with the >>>>>>>> phone number to obtain the name. Recently, due to charges >>>>>>>> levied on the terminating carrier by the originating carrier to >>>>>>>> query the database, alternatives have arose where large consumer >>>>>>>> oriented databases are queried that independently match name >>>>>>>> with telephone number without reference to the originating >>>>>>>> carrier's information. When the databases were operated by >>>>>>>> large established telcos, the reliability of the data was good. >>>>>>>> However, some service providers are now lax in how the data is >>>>>>>> populated, and some even advertise the ability to allow any name >>>>>>>> to be used with a number. This has significantly >> erod >>>>>>> ed >>>>>>>> the usefulness of the service. Where caller name service is provided, it replaces the display of the calling party number, although smart phones will usually substitute their local contact list name for whatever is provided by the calling name service. This means that if stir succeeds in improving the quality of the calling party number, but no solution is provided for calling party name, fraudsters may still be able to disguise their activities. >>>>>>>> >>>>>>>> This work proposes to change how caller name is carried to using the existing display name portion of the SIP URI in the From or P-A-I field. The name would be carried in the signaling from origination to termination. This capability exists today, although the service providers typically do not restrict or asses what name the caller asserts. Therefore, along with the name would come a form of validation that the name is genuine, and, for calls from businesses, the type of business it is from. >>>>>>>> >>>>>>>> Validation of names is exceedingly difficult, and this work does >>>>>>>> not propose a solution that will provide a name with absolute >>>>>>>> certainty that it is genuine and associated with the telephone >>>>>>>> number of the calling party. It does propose that the data be >>>>>>>> vetted through some process, which may not result in a simple >>>>>>>> "this is the name" result. Rather, the vetting process may >>>>>>>> provide a name, but accompany it with a confidence factor(score) >>>>>>>> indicating the source's assessment of the likelihood that the >>>>>>>> name is represents the calling party. Confidence would be a >>>>>>>> simple 0-100 scaler, without an attempt to precisely define or >>>>>>>> normalize it between sources. That means that the termination >>>>>>>> side would have to evaluate the confidence factor and the source >>>>>>>> of the confidence together to decide how much to trust the name. >>>>>>>> The termination could take a variety of actions based on the >>>>>>>> source and the claimed confidence. Doing so implies that the >>>>>>>> number of sources is limited so that eva >> luati >>>>>>> ng >>>>>>>> the source for trustworthiness can be accomplished. >>>>>>>> >>>>>>>> Vetting the name at the source is more likely to be of value, because the source may have a variety of other information about the party the name is assigned to that can be used to improve the reliability of the vetting process. For example, address, other phone numbers, age, email addresses, domains (for businesses), etc can be used to provide much higher confidence that the name accurately represents the calling party than just the number known at the termination side. >>>>>>>> >>>>>>>> Besides the name, when a call is made from a business, the type of business can provide important information to the caller when deciding to answer the call, or trust the caller. The type of business would be a selection from an existing taxonomy of business types and would be relatively high level ("bank", "florist", "doctor"). >>>>>>>> >>>>>>>> The name, type of business (if appropriate), the source of the data, the confidence indicator and some indication of the vetting process would accompany the name in a new header in a secure manner -- secure in the sense that the number, the name, type, the source, and the sources' asserted confidence of the name is signed by the source. >>>>>>>> >>>>>>>> If the termination side did not trust the source, or it did, but the confidence was too low in its opinion, the termination may take a number of actions, including, but not limited to: >>>>>>>> a) Refuse the call, or send it to voicemail >>>>>>>> b) Use an independent source of names, like the alternative name >>>>>>>> suppliers that exist today to display an alternate name >>>>>>>> c) Provide a visual or audible warning to the user that the name >>>>>>>> may not be valid >>>>>>>> d) Provide a visual or audible representation of the confidence, >>>>>>>> possibly simplified (red/orange/yellow/green) >>>>>>>> e) Provide a caller feedback (thumbs up/down) mechanism to >>>>>>>> further develop a rating of the source, or the specific >>>>>>>> name/number pair >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> On Sep 2, 2013, at 10:38 PM, Henning Schulzrinne wrote: >>>>>>>> >>>>>>>>> I didn't want to get into solution space, but I'm a bit surprised by the question, since that's exactly what's been discussed, at length. The idea was that, unlike today, the textual callerID is generally traceable to the originating carrier and/or originating entity, for the Organization/From split I provided as an example earlier. >>>>>>>>> >>>>>>>>> As pointed out, that's not always true today, given that the destination has no clue which database is being used and who inserted the information there - a tier-1 carrier based on business records, listyourself.net based on caller assertion or some random white pages service based on who-knows. >>>>>>>>> >>>>>>>>> For the additional information, we have, as pointed out repeatedly, numerous third-party databases, both private and governmental. The originating carrier or possibly the originator can obtain and sign that information as a value-add. The ARID approach is another possibility. >>>>>>>>> >>>>>>>>> I've tried to provide very specific examples of how this could work, but am obviously not getting the point across. >>>>>>>>> >>>>>>>>> ________________________________________ >>>>>>>>> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >>>>>>>>> Sent: Monday, September 02, 2013 11:51 AM >>>>>>>>> To: Henning Schulzrinne >>>>>>>>> Cc: Stephen Farrell; cnit@ietf.org >>>>>>>>> Subject: Re: [cnit] what's the actual problem here? >>>>>>>>> >>>>>>>>> >>>>>>>>>> (b) indicate provenance of the information (e.g., was this >>>>>>>>>> inserted by the caller, the caller's carrier or by the >>>>>>>>>> receiving carrier, CNAM-style) >>>>>>>>> >>>>>>>>> I think that might be actually quite hard to accomplish, in a trustworthy manner. The terminating carrier would know whether it got the name from a LIDB or 3rd-party CNAM; but even in the LIDB case it doesn't know where the LIDB data ultimately came from other than the LIDB AS for the calling number. >>>>>>>>> >>>>>>>>> Since the premise for this discussion is that calling names are not trustworthy anymore (?), I'm assuming the LIDB AS'es are letting their data be populated by untrustworthy sources. Is that correct? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -hadriel >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> _______________________________________________ >> 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 > From kent@bbn.com Thu Sep 5 07:41:17 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B24911E80EC for ; Thu, 5 Sep 2013 07:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy7N9XU2Jv64 for ; Thu, 5 Sep 2013 07:41:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5367411E81BD for ; Thu, 5 Sep 2013 07:41:11 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54304) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VHak1-0008qU-PJ; Thu, 05 Sep 2013 10:41:01 -0400 Message-ID: <522897FD.7000309@bbn.com> Date: Thu, 05 Sep 2013 10:41:01 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Kyzivat References: <52225DF8.4000000@cs.tcd.ie> , <9AF295E8-3824-4440-9069-4A30FB374812@oracle.com> <04FF23F0-158D-4061-ABFA-7F264C46A8C1@brianrosen.net> <52263907.4050602@alum.mit.edu> <8FD18CBB-B150-4B43-ACCB-A44602DAF8EC@brianrosen.net> <52263E86.3020403@alum.mit.edu> <52278EE6.1090400@alum.mit.edu> <5227B32B.1090905@alum.mit.edu> In-Reply-To: <5227B32B.1090905@alum.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "cnit@ietf.org" , 'Brian Rosen' , Henning Schulzrinne Subject: Re: [cnit] what's the actual problem here? X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:41:17 -0000 Paul, I agree with your assessment about the potential role of the callee SP evaluating the trustworthiness of the caller SP wrt a caller's asserted name. I still worry about making this intelligible to residential (vs. business or call center) users, but at least this strategy addresses the concerns about bad caller SPs. Steve From ietf-secretariat@ietf.org Thu Sep 5 09:51:11 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6800F21E8134; Thu, 5 Sep 2013 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.05 X-Spam-Level: X-Spam-Status: No, score=-103.05 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb+XK8ql0sUR; Thu, 5 Sep 2013 09:51:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA9A21E80F1; Thu, 5 Sep 2013 09:51:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130905165110.30634.83857.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 09:51:10 -0700 Cc: cnit@ietf.org, hadrielk@yahoo.com, br@brianrosen.net Subject: [cnit] New Non-WG Mailing List: cnit -- Calling Name Identity Trust discussion list X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 16:51:11 -0000 A new IETF non-working group email list has been created. List address: cnit@ietf.org Archive: http://www.ietf.org/mail-archive/web/cnit/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/cnit Purpose: This list is for discussions relating to providing source calling = name identity for SIP-based call requests, in some trusted fashion. This is currently a research item, and is related to the Secure Telephone Identity Revisited (STIR) Working Group. STIR is for validating source calling telephone numbers, while CNIT (pronounced 'seen it') is for providing valid textual calling names. For additional information, please contact the list administrators.