From hadriel.kaplan@oracle.com Tue Aug 27 11:44:55 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 B7F1811E81BC for ; Tue, 27 Aug 2013 11:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 jX96FdRCdvi0 for ; Tue, 27 Aug 2013 11:44:49 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0AA11E819B for ; Tue, 27 Aug 2013 11:44:46 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7RIig7h031907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Aug 2013 18:44:43 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RIig5j024772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Aug 2013 18:44:42 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RIifxB010213 for ; Tue, 27 Aug 2013 18:44:41 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 11:44:41 -0700 From: Hadriel Kaplan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <740C389D-422C-4945-AA6A-CFE9455170C6@oracle.com> Date: Tue, 27 Aug 2013 14:44:40 -0400 To: cnit@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [cnit] Testing 123 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, 27 Aug 2013 18:44:55 -0000 This is a test message. -hadriel From hadriel.kaplan@oracle.com Tue Aug 27 13:37:32 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 AB2E021E8084 for ; Tue, 27 Aug 2013 13:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 CZWolgNUS4eI for ; Tue, 27 Aug 2013 13:37:26 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1045221F9B9F for ; Tue, 27 Aug 2013 13:37:25 -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 r7RKaR9p014494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 20:36:28 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RKaPJc007319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 20:36:25 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RKaOaJ026007; Tue, 27 Aug 2013 20:36:24 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 13:36:24 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 27 Aug 2013 16:36:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Henning Schulzrinne , "cnit@ietf.org" , Alex Bobotek , "Dwight, Timothy M \(Tim\)" , Stephen Farrell 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, 27 Aug 2013 20:37:32 -0000 OK, but if these databases work so well, then what's the problem we need = to fix? -hadriel On Aug 27, 2013, at 3:01 PM, Brian Rosen wrote: > No one suggested we do that in a PKI/DKIM that is issuing credentials = for phone numbers. I merely wish to be able to carry the validation = information as asserted by the entity signing the number. The validator = service for the name is likely different from the number delegation = authority. =20 >=20 > I repeat, often, that the mechanisms we use to do the name validation = are not perfect, and they are most often local (i.e. a given validation = database often only covers one, or a very small number of countries). = If you attempted to use Stiof=E1n O'Fearghail assuming you presently = resided in the U.S., you would get a very low score, unless you have = regularly used that name in a variety of commercial circumstances or = public records. Even if your birth certificate used that version of = your name, if you didn't regularly use it, the database would score it = low, even if you supplied other information about yourself. The same is = very likely true of the databases that cover Ireland, unless, again, = that was how you represented yourself commonly, especially in commercial = transactions or public records, but I am less familiar with them than = the U.S. databases. >=20 > Each of these databases has different sources of data that it builds = on, and they have different methods of correcting bad data. They are, = however, pretty darn reliable over all, even though they are not = perfect. I would not suggest that we standardize how these databases = work. We only need to recognize that they exist, that they supply a = score, and that they work better with more information suppled on a = query, which leads me to try to get validation done at the origination = side, where more information is typically available. We don't have to = standardize queries to these databases, or anything other than the range = of the score, where 0-100 is a generally acceptable range. >=20 > Brian >=20 >=20 >=20 >=20 > On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell = wrote: > On =FEri 27.=E1g=FA 2013 18:21, Brian Rosen wrote: >=20 > We DO know how to do reasonable, but not entirely accurate, validation = of names against numbers, especially if, as we can reasonably do, we get = additional information from the origination service provider to do the = validation. We do that now, pretty successfully. We can imagine = extending the kinds of things we do now in the direction Tim, Henning, = and others have suggested - primarily, the notion of having a taxonomy = of callers (like "bank") and labeling the caller with the taxonomy in a = reasonably accurate way. Based on the kinds of databases that exist, = doing validation against an agreed upon taxonomy is not research. > FWIW, I don't think we know how to do that in a PKI (or DKIM-like = equivalent) that is being established to issue credentials just for = phone numbers. I think I saw Steve Kent say the same thing earlier as = well. Dealing with people's > names and businesses names like that just has a lot of complexity, or = at least has had in any context in which I've encountered the problem. = Just to throw one of many possible examples into the picture, the name = Stiof=E1n O'Fearghail would likely have to be accepted for me if an = Irish regulator were deploying a STIR system that had to support = people's names - are you saying you know how to handle all the i18n = issues with naming that'd come up? >=20 > S. >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Tue Aug 27 13:42:07 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 9F13B21F9DA9 for ; Tue, 27 Aug 2013 13:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.825 X-Spam-Level: X-Spam-Status: No, score=-102.825 tagged_above=-999 required=5 tests=[AWL=0.774, 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 BXquGlD04CuK for ; Tue, 27 Aug 2013 13:42:03 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB1A21F9D95 for ; Tue, 27 Aug 2013 13:42:02 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so1759220oag.14 for ; Tue, 27 Aug 2013 13:42:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=w8PGbMCg1Q1YQKmC4G2pfvZi0HfIIxvmZBcoNhdlvnY=; b=WLRqCnQI2zShHw1Tm20rnUHdSt+ithD+WgkNzYgMGs1cePBjkSTfAv+9iP4f5fLJK4 nWcFJgiBoRGpg8PT3T/R0/nmmehpPFyeTJq82TZKIjydNwa9KKB3FAyJTYbi+sRG7oln sMSvdB3OKDdvm3URzTCDgu5e+CcCN+e2Hs4zytCWAO6SNSPapmtn9d2vWgIPoCCj2M99 ogvDWjFgsKFNjk3fFWhNBtXOwiIaHTocU94U7B7CKOOHObsCB+FaLfaeM9ek1BuqCo+4 UZ99S+bUMtp56oCcwSw9aBpfU+68GDXms5NZboT6BPKlfzoezLbZei9HRFpYHTds4QP+ XZaA== X-Gm-Message-State: ALoCoQmZPRk9Rs5u2J4l00LqVXgV6UPx41WT3fq+iA7IjM9xxR819YN1B0RYqlqkEl8n9vLH5T4j X-Received: by 10.60.121.103 with SMTP id lj7mr20359563oeb.25.1377636121925; Tue, 27 Aug 2013 13:42:01 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id uz16sm21939809obc.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 13:42:01 -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: Date: Tue, 27 Aug 2013 16:41:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: Henning Schulzrinne , "cnit@ietf.org" , Alex Bobotek , "Dwight, Timothy M \(Tim\)" , Stephen Farrell 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, 27 Aug 2013 20:42:07 -0000 As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. What we need is to do the dip at the origination side, where you have = more information to make the score larger, and securely carry it in the = SIP signaling. That is the problem to be solved - I have the name, the = score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). Brian On Aug 27, 2013, at 4:36 PM, Hadriel Kaplan = wrote: >=20 > OK, but if these databases work so well, then what's the problem we = need to fix? >=20 > -hadriel >=20 > On Aug 27, 2013, at 3:01 PM, Brian Rosen wrote: >=20 >> No one suggested we do that in a PKI/DKIM that is issuing credentials = for phone numbers. I merely wish to be able to carry the validation = information as asserted by the entity signing the number. The validator = service for the name is likely different from the number delegation = authority. =20 >>=20 >> I repeat, often, that the mechanisms we use to do the name validation = are not perfect, and they are most often local (i.e. a given validation = database often only covers one, or a very small number of countries). = If you attempted to use Stiof=E1n O'Fearghail assuming you presently = resided in the U.S., you would get a very low score, unless you have = regularly used that name in a variety of commercial circumstances or = public records. Even if your birth certificate used that version of = your name, if you didn't regularly use it, the database would score it = low, even if you supplied other information about yourself. The same is = very likely true of the databases that cover Ireland, unless, again, = that was how you represented yourself commonly, especially in commercial = transactions or public records, but I am less familiar with them than = the U.S. databases. >>=20 >> Each of these databases has different sources of data that it builds = on, and they have different methods of correcting bad data. They are, = however, pretty darn reliable over all, even though they are not = perfect. I would not suggest that we standardize how these databases = work. We only need to recognize that they exist, that they supply a = score, and that they work better with more information suppled on a = query, which leads me to try to get validation done at the origination = side, where more information is typically available. We don't have to = standardize queries to these databases, or anything other than the range = of the score, where 0-100 is a generally acceptable range. >>=20 >> Brian >>=20 >>=20 >>=20 >>=20 >> On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell = wrote: >> On =FEri 27.=E1g=FA 2013 18:21, Brian Rosen wrote: >>=20 >> We DO know how to do reasonable, but not entirely accurate, = validation of names against numbers, especially if, as we can reasonably = do, we get additional information from the origination service provider = to do the validation. We do that now, pretty successfully. We can = imagine extending the kinds of things we do now in the direction Tim, = Henning, and others have suggested - primarily, the notion of having a = taxonomy of callers (like "bank") and labeling the caller with the = taxonomy in a reasonably accurate way. Based on the kinds of databases = that exist, doing validation against an agreed upon taxonomy is not = research. >> FWIW, I don't think we know how to do that in a PKI (or DKIM-like = equivalent) that is being established to issue credentials just for = phone numbers. I think I saw Steve Kent say the same thing earlier as = well. Dealing with people's >> names and businesses names like that just has a lot of complexity, or = at least has had in any context in which I've encountered the problem. = Just to throw one of many possible examples into the picture, the name = Stiof=E1n O'Fearghail would likely have to be accepted for me if an = Irish regulator were deploying a STIR system that had to support = people's names - are you saying you know how to handle all the i18n = issues with naming that'd come up? >>=20 >> S. >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From stephen.farrell@cs.tcd.ie Tue Aug 27 14:29: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 99CD121E80E4 for ; Tue, 27 Aug 2013 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=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 VImmVib2bpDb for ; Tue, 27 Aug 2013 14:29: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 315C821E80C9 for ; Tue, 27 Aug 2013 14:29:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7358DBE6E; Tue, 27 Aug 2013 22:29: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 3UI0LUvL5xWS; Tue, 27 Aug 2013 22:29:04 +0100 (IST) Received: from [192.168.1.45] (nova006-184.cust-nat.nova.is [46.182.184.6]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A8008BE5D; Tue, 27 Aug 2013 22:28:59 +0100 (IST) Message-ID: <521D1A14.5080708@cs.tcd.ie> Date: Tue, 27 Aug 2013 21:28:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050606090602000302070604" Cc: cnit@ietf.org, Henning Schulzrinne 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, 27 Aug 2013 21:29:18 -0000 This is a multi-part message in MIME format. --------------050606090602000302070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit -stir, +cnit (to which I'm not yet subscribed) On þri 27.ágú 2013 19:01, Brian Rosen wrote: > No one suggested we do that in a PKI/DKIM that is issuing credentials > for phone numbers. I merely wish to be able to carry the validation > information as asserted by the entity signing the number. The > validator service for the name is likely different from the number > delegation authority. > > I repeat, often, that the mechanisms we use to do the name validation > are not perfect, and they are most often local (i.e. a given > validation database often only covers one, or a very small number of > countries). If you attempted to use Stiofán O'Fearghail assuming you > presently resided in the U.S., you would get a very low score, unless > you have regularly used that name in a variety of commercial > circumstances or public records. Even if your birth certificate used > that version of your name, if you didn't regularly use it, the > database would score it low, even if you supplied other information > about yourself. The same is very likely true of the databases that > cover Ireland, unless, again, that was how you represented yourself > commonly, especially in commercial transactions or public records, but > I am less familiar with them than the U.S. databases. I thought you had just said that reputation systems for this were not understood? In any case, you missed my point, or I wasn't clear enough. In any Irish caller-ID context with names, its quite possible that COMREG (the Irish FCC equivalent) might insist that names be provided in both Irish and English (where the name differs in the two languages, which is mostly but not always the case) or in whichever the caller or callee prefers - it'd be politics that determined the actual choice probably and your putative caller name PKI would need to cater for that kind of complexity. Its just a hard hard problem and I doubt that its at all as well understood as you claimed to be honest. S. > > Each of these databases has different sources of data that it builds > on, and they have different methods of correcting bad data. They are, > however, pretty darn reliable over all, even though they are not > perfect. I would not suggest that we standardize how these databases > work. We only need to recognize that they exist, that they supply a > score, and that they work better with more information suppled on a > query, which leads me to try to get validation done at the origination > side, where more information is typically available. We don't have to > standardize queries to these databases, or anything other than the > range of the score, where 0-100 is a generally acceptable range. > > Brian > > > > > On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell > > wrote: > > On þri 27.ágú 2013 18:21, Brian Rosen wrote: > > > We DO know how to do reasonable, but not entirely accurate, > validation of names against numbers, especially if, as we can > reasonably do, we get additional information from the > origination service provider to do the validation. We do that > now, pretty successfully. We can imagine extending the kinds > of things we do now in the direction Tim, Henning, and others > have suggested - primarily, the notion of having a taxonomy of > callers (like "bank") and labeling the caller with the > taxonomy in a reasonably accurate way. Based on the kinds of > databases that exist, doing validation against an agreed upon > taxonomy is not research. > > FWIW, I don't think we know how to do that in a PKI (or DKIM-like > equivalent) that is being established to issue credentials just > for phone numbers. I think I saw Steve Kent say the same thing > earlier as well. Dealing with people's > names and businesses names like that just has a lot of complexity, > or at least has had in any context in which I've encountered the > problem. Just to throw one of many possible examples into the > picture, the name Stiofán O'Fearghail would likely have to be > accepted for me if an Irish regulator were deploying a STIR system > that had to support people's names - are you saying you know how > to handle all the i18n issues with naming that'd come up? > > S. > > --------------050606090602000302070604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

-stir, +cnit (to which I'm not yet subscribed)

On þri 27.ágú 2013 19:01, Brian Rosen wrote:
No one suggested we do that in a PKI/DKIM that is issuing credentials for phone numbers.  I merely wish to be able to carry the validation information as asserted by the entity signing the number.  The validator service for the name is likely different from the number delegation authority.  

I repeat, often, that the mechanisms we use to do the name validation are not perfect, and they are most often local (i.e. a given validation database often only covers one, or a very small number of countries).  If you attempted to use Stiofán O'Fearghail assuming you presently resided in the U.S., you would get a very low score, unless you have regularly used that name in a variety of commercial circumstances or public records.  Even if your birth certificate used that version of your name, if you didn't regularly use it, the database would score it low, even if you supplied other information about yourself.  The same is very likely true of the databases that cover Ireland, unless, again, that was how you represented yourself commonly, especially in commercial transactions or public records, but I am less familiar with them than the U.S. databases.
I thought you had just said that reputation systems for this were not understood?

In any case, you missed my point, or I wasn't clear enough. In any Irish caller-ID context with names, its quite possible that COMREG (the Irish FCC equivalent) might insist that names be provided in both Irish and English (where the name differs in the two languages, which is mostly but not always the case) or in whichever the caller or callee prefers - it'd be politics that determined the actual choice probably and your putative caller name PKI would need to cater for that kind of complexity.  Its just a hard hard problem and I doubt that its at all as well understood as you claimed to be honest.

S.



Each of these databases has different sources of data that it builds on, and they have different methods of correcting bad data.  They are, however, pretty darn reliable over all, even though they are not perfect.   I would not suggest that we standardize how these databases work.  We only need to recognize that they exist, that they supply a score, and that they work better with more information suppled on a query, which leads me to try to get validation done at the origination side, where more information is typically available.  We don't have to standardize queries to these databases, or anything other than the range of the score, where 0-100 is a generally acceptable range.

Brian




On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
On þri 27.ágú 2013 18:21, Brian Rosen wrote:

We DO know how to do reasonable, but not entirely accurate, validation of names against numbers, especially if, as we can reasonably do, we get additional information from the origination service provider to do the validation.  We do that now, pretty successfully.  We can imagine extending the kinds of things we do now in the direction Tim, Henning, and others have suggested - primarily, the notion of having a taxonomy of callers (like "bank") and labeling the caller with the taxonomy in a reasonably accurate way.  Based on the kinds of databases that exist, doing validation against an agreed upon taxonomy is not research.
FWIW, I don't think we know how to do that in a PKI (or DKIM-like equivalent) that is being established to issue credentials just for phone numbers. I think I saw Steve Kent say the same thing earlier as well. Dealing with people's
names and businesses names like that just has a lot of complexity, or at least has had in any context in which I've encountered the problem. Just to throw one of many possible examples into the picture, the name Stiofán O'Fearghail would likely have to be accepted for me if an Irish regulator were deploying a STIR system that had to support people's names - are you saying you know how to handle all the i18n issues with naming that'd come up?

S.



--------------050606090602000302070604-- From br@brianrosen.net Tue Aug 27 14:46:40 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 6C6AD21E8084 for ; Tue, 27 Aug 2013 14:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.86 X-Spam-Level: X-Spam-Status: No, score=-102.86 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nR45UWubosji for ; Tue, 27 Aug 2013 14:46:26 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id D517221E805D for ; Tue, 27 Aug 2013 14:46:25 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id s14so2995760qeb.9 for ; Tue, 27 Aug 2013 14:46:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=jr5SZ8vpKv7/EdzLri51FeZxDrPLLaEQbiZO9+JTaO0=; b=T4VUx7sBfqNBoLU3jBB7Q5x8kJMb40jtXB6mZaHshPjb20wCHYP4cAv9sEO2pQkOmO N9vsqgE0tbdUomMR6123fqEvQsP5J1lVTtNbFRvXhVDpfbJ0k9IruRNBeIW5MGzplS6p 0SYbkyJZKtwMEefNj3dsL3nCSrC8kL/X6L8UFKVF5NetefUeY8mrJQP5iPE403F4M1Ww gjEvJz9jL1Ud87aFJVFr3CpGA9rSyDH9xjPl4mk5VfFkapZ3loMbULODg9nhqCvM9Fcx XcJ+w1pW4JKGcTS11uPy0oOrosAUv/nJV6ayIa97fl8rzRAevqaVXNWR7siJsnz9mAyW 8/Jw== X-Gm-Message-State: ALoCoQkzjl/p2bHCLDwTqBM86lLS9LEF8YFdSvKuWKJG1SmyQuTPLa4zGY4CFkT9jcFqbF4R5mgL X-Received: by 10.49.94.241 with SMTP id df17mr26176635qeb.18.1377639985156; Tue, 27 Aug 2013 14:46:25 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id m10sm32143509qae.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 14:46:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A782123E-8FC8-406F-8F25-A4E245A96EF6" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <521D1A14.5080708@cs.tcd.ie> Date: Tue, 27 Aug 2013 17:46:22 -0400 Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org, Henning Schulzrinne 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, 27 Aug 2013 21:46:40 -0000 --Apple-Mail=_A782123E-8FC8-406F-8F25-A4E245A96EF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It's possible for regulators to make something that was possible in an = engineering sense become impossible by poor choice of regulation. I = would never dispute that. However, if Irish names were not commonly used in commerce, then the = databases that provide authentication for a wide variety of uses = including customer support calls, credit decisions, ordering pizza and = others would not work if you tried to claim you were Stiof=E1n = O'Fearghail. If they were not commonly used, and COMREG required they = be used, we might have a problem. Can't engineer a way around that. We'd have the same problem if they required Gaelic. But if the name you = assert is the same one you use with your bank, your car dealer and your = pizza parlor, then it will be given a decent score. Brian On Aug 27, 2013, at 5:28 PM, Stephen Farrell = wrote: >=20 > -stir, +cnit (to which I'm not yet subscribed) >=20 > On =FEri 27.=E1g=FA 2013 19:01, Brian Rosen wrote: >> No one suggested we do that in a PKI/DKIM that is issuing credentials = for phone numbers. I merely wish to be able to carry the validation = information as asserted by the entity signing the number. The validator = service for the name is likely different from the number delegation = authority. =20 >>=20 >> I repeat, often, that the mechanisms we use to do the name validation = are not perfect, and they are most often local (i.e. a given validation = database often only covers one, or a very small number of countries). = If you attempted to use Stiof=E1n O'Fearghail assuming you presently = resided in the U.S., you would get a very low score, unless you have = regularly used that name in a variety of commercial circumstances or = public records. Even if your birth certificate used that = version of your name, if you didn't regularly use it, the database would = score it low, even if you supplied other information about yourself. = The same is very likely true of the databases that cover Ireland, = unless, again, that was how you represented yourself commonly, = especially in commercial transactions or public records, but I am less = familiar with them than the U.S. databases. > I thought you had just said that reputation systems for this were not = understood? >=20 > In any case, you missed my point, or I wasn't clear enough. In any = Irish caller-ID context with names, its quite possible that COMREG (the = Irish FCC equivalent) might insist that names be provided in both Irish = and English (where the name differs in the two languages, which is = mostly but not always the case) or in whichever the caller or callee = prefers - it'd be politics that determined the actual choice probably = and your putative caller name PKI would need to cater for that kind of = complexity. Its just a hard hard problem and I doubt that its at all as = well understood as you claimed to be honest. >=20 > S. >=20 >=20 >>=20 >> Each of these databases has different sources of data that it builds = on, and they have different methods of correcting bad data. They are, = however, pretty darn reliable over all, even though they are not = perfect. I would not suggest that we standardize how these databases = work. We only need to recognize that they exist, that they supply a = score, and that they work better with more information suppled on a = query, which leads me to try to get validation done at the origination = side, where more information is typically available. We don't have to = standardize queries to these databases, or anything other than the range = of the score, where 0-100 is a generally acceptable range. >>=20 >> Brian >>=20 >>=20 >>=20 >>=20 >> On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell = wrote: >> On =FEri 27.=E1g=FA 2013 18:21, Brian Rosen wrote: >>=20 >> We DO know how to do reasonable, but not entirely accurate, = validation of names against numbers, especially if, as we can reasonably = do, we get additional information from the origination service provider = to do the validation. We do that now, pretty successfully. We can = imagine extending the kinds of things we do now in the direction Tim, = Henning, and others have suggested - primarily, the notion of having a = taxonomy of callers (like "bank") and labeling the caller with the = taxonomy in a reasonably accurate way. Based on the kinds of databases = that exist, doing validation against an agreed upon taxonomy is not = research. >> FWIW, I don't think we know how to do that in a PKI (or DKIM-like = equivalent) that is being established to issue credentials = just for phone numbers. I think I saw Steve Kent say the same thing = earlier as well. Dealing with people's >> names and businesses names like that just has a lot of complexity, or = at least has had in any context in which I've encountered the problem. = Just to throw one of many possible examples into the picture, the name = Stiof=E1n O'Fearghail would likely have to be accepted for me if an = Irish regulator were deploying a STIR system that had to support = people's names - are you saying you know how to handle all the i18n = issues with naming that'd come up? >>=20 >> S. >>=20 >>=20 >=20 --Apple-Mail=_A782123E-8FC8-406F-8F25-A4E245A96EF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It's = possible for regulators to make something that was possible in an = engineering sense become impossible by poor choice of regulation. =  I would never dispute that.

However, if Irish = names were not commonly used in commerce, then the databases that = provide authentication for a wide variety of uses including customer = support calls, credit decisions, ordering pizza and others would not = work if you tried to claim you were Stiof=E1n O'Fearghail. =  If they were not commonly used, and COMREG required they be used, = we might have a problem.  Can't engineer a way around = that.

We'd have the same problem if they = required Gaelic.  But if the name you assert is the same one you = use with your bank, your car dealer and your pizza parlor, then it will = be given a decent = score.

Brian

O= n Aug 27, 2013, at 5:28 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:

=20 =20

-stir, +cnit (to which I'm not yet subscribed)

On =FEri 27.=E1g=FA 2013 19:01, Brian Rosen wrote:
No one suggested we do that in a PKI/DKIM that is issuing credentials for phone numbers.  I merely wish to be = able to carry the validation information as asserted by the entity signing the number.  The validator service for the name is likely different from the number delegation authority.  

I repeat, often, that the mechanisms we use to do the name validation are not perfect, and they are most often local (i.e. a given validation database often only covers one, or a very small number of countries).  If you attempted to = use Stiof=E1n O'Fearghail assuming you presently resided in the U.S., you would get a very low score, unless you have regularly used that name in a variety of commercial circumstances or public records.  Even if your birth certificate used that = version of your name, if you didn't regularly use it, the database would score it low, even if you supplied other information about yourself.  The same is very likely true of the databases that cover Ireland, unless, again, that was how you represented yourself commonly, especially in commercial transactions or public records, but I am less familiar with them than the U.S. databases.
I thought you had just said that reputation systems for this were not understood?

In any case, you missed my point, or I wasn't clear enough. In any Irish caller-ID context with names, its quite possible that COMREG (the Irish FCC equivalent) might insist that names be provided in both Irish and English (where the name differs in the two languages, which is mostly but not always the case) or in whichever the caller or callee prefers - it'd be politics that determined the actual choice probably and your putative caller name PKI would need to cater for that kind of complexity.  Its just a hard hard = problem and I doubt that its at all as well understood as you claimed to be honest.

S.



Each of these databases has different sources of data that it builds on, and they have different methods of correcting bad data.  They are, however, pretty darn reliable over = all, even though they are not perfect.   I would not suggest = that we standardize how these databases work.  We only need = to recognize that they exist, that they supply a score, and that they work better with more information suppled on a query, which leads me to try to get validation done at the origination side, where more information is typically available.  We don't have to standardize queries to = these databases, or anything other than the range of the score, where 0-100 is a generally acceptable range.

Brian




On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
On =FEri 27.=E1g=FA 2013 18:21, Brian = Rosen wrote:

We DO know how to do reasonable, but not entirely accurate, validation of names against numbers, especially if, as we can reasonably do, we get additional information from the origination service provider to do the validation.  We do that now, = pretty successfully.  We can imagine extending the kinds = of things we do now in the direction Tim, Henning, and others have suggested - primarily, the notion of having a taxonomy of callers (like "bank") and labeling the caller with the taxonomy in a reasonably accurate way.  Based on the kinds of databases that exist, doing validation against an agreed upon taxonomy is not research.
FWIW, I don't think we know how to do that in a PKI (or DKIM-like equivalent) that is being established to issue credentials just for phone numbers. I think I saw Steve Kent say the same thing earlier as well. Dealing with = people's
names and businesses names like that just has a lot of complexity, or at least has had in any context in which I've encountered the problem. Just to throw one of many possible examples into the picture, the name Stiof=E1n O'Fearghail would likely have to be accepted for me if an Irish regulator were deploying a STIR system that had to support people's names - are you saying you know how to handle all the i18n issues with naming that'd come up?

S.




= --Apple-Mail=_A782123E-8FC8-406F-8F25-A4E245A96EF6-- From hadriel.kaplan@oracle.com Tue Aug 27 15:22:52 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 CF04F21F93BA for ; Tue, 27 Aug 2013 15:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 GukCeLDUN3WS for ; Tue, 27 Aug 2013 15:22:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A658A11E8220 for ; Tue, 27 Aug 2013 15:22:41 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7RMMWt5020385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 22:22:33 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RMMS6H022561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 22:22:29 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RMMSUe022558; Tue, 27 Aug 2013 22:22:28 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 15:22:27 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> Date: Tue, 27 Aug 2013 18:22:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "cnit@ietf.org" , Alex Bobotek , "Dwight, Timothy M \(Tim\)" , Stephen Farrell , Henning Schulzrinne 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, 27 Aug 2013 22:22:52 -0000 On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: > As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. Yes, I know they're queried on termination; and yes, I know they're = queried using the source telephone number. STIR will provide validity = for that source number, so that you can't pretend to be a source number = you aren't. That should make things better for calling names, if the = content of the calling name databases is accurate. You've been claiming = the content of the databases is fairly accurate. (and as far as I can = tell, they have been relatively accurate so far, for at least CNAM = databases though maybe not LIDB ones) I know many folks don't like the CNAM model, but I believe they don't = like it due to the pricing model - not due to bad content, nor due to = having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. I don't know what you mean by "that gets poor scores". As far as I = know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? > What we need is to do the dip at the origination side, where you have = more information to make the score larger, and securely carry it in the = SIP signaling. That is the problem to be solved - I have the name, the = score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). I think that jumps to a solution - presumably the problem is "calling = names aren't reliable"; the problem is not "we can't send scores = securely in SIP". This whole topic is reminiscent of the debates the SIPPING WG had years = ago on: draft-wing-sipping-spam-score draft-schwartz-sipping-spit-saml -hadriel From stephen.farrell@cs.tcd.ie Tue Aug 27 15:30: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 54F2D21F9D7A for ; Tue, 27 Aug 2013 15:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2, 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 zzwLFIjw1M80 for ; Tue, 27 Aug 2013 15:30:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E24C621F9DB4 for ; Tue, 27 Aug 2013 15:30:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B5E78BE5C; Tue, 27 Aug 2013 23:30:41 +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 yQrG5h9RaPXE; Tue, 27 Aug 2013 23:30:41 +0100 (IST) Received: from [192.168.1.45] (nova006-184.cust-nat.nova.is [46.182.184.6]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B177DBE56; Tue, 27 Aug 2013 23:30:35 +0100 (IST) Message-ID: <521D2887.40502@cs.tcd.ie> Date: Tue, 27 Aug 2013 22:30:31 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: cnit@ietf.org, Henning Schulzrinne 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, 27 Aug 2013 22:30:53 -0000 On þri 27.ágú 2013 21:46, Brian Rosen wrote: > > We'd have the same problem if they required Gaelic. But if the name > you assert is the same one you use with your bank, your car dealer and > your pizza parlor, then it will be given a decent score. I was talking about Gaelige - you see the point is that once you consider naming people, you get these kind of complexities. In the specific case, Irish (Gaelige) is the first official language of Ireland and that wins in all sorts of ways (e.g. street signs, our University letterhead) and would likely win in this case too. So the putative PKI or whatever would have to support Irish and other oddities of naming, and I'm sure many other countries have their own fine oddities too;-) All I'm saying is: this is complicated stuff and not simple and claiming its a solved problem is not credible. S. From br@brianrosen.net Tue Aug 27 15:33:42 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 AEE4611E83A9 for ; Tue, 27 Aug 2013 15:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.893 X-Spam-Level: X-Spam-Status: No, score=-103.893 tagged_above=-999 required=5 tests=[AWL=1.706, BAYES_00=-2.599, GB_I_LETTER=-2, 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 TUY36fQPkoLB for ; Tue, 27 Aug 2013 15:33:36 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id E6BF911E83B5 for ; Tue, 27 Aug 2013 15:33:33 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id s14so2979922qeb.37 for ; Tue, 27 Aug 2013 15:33:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=7dKWNyVN50/bPx0p2Vv+t8MBRYppdZAGbWQTyTHjgbg=; b=Ojd2ttFn6Rw2Z/e/0EGcHdCCwJx+hRGOl+klTILV9jlGikdLxoujkoBrq/f5hr0DZi z8liBk+EzKmVvOamnCEnfjvgzJg8wu4eji8wQciKVseL0qkGzkF0h2PAyTJGGSjlEC5g YZwXGRUsLata4NQpiWxPww7JQ0wAyUmjUe5zt28MT2us4XWzn0O8NdHG3lGdkYWWnfVK x8lti/lXtx7tjzwFQlbb4kjyhgfCwcm2/I1cBQo8OuBRlnzDlB0l5q03uhesowx/pKkJ V2Pc/zRulaNcmXuf9Y7obS5k1JKgnHqiP8F9JKWgurDppy4rYF2NtQeg1PrncISbQnlL txhQ== X-Gm-Message-State: ALoCoQmRSFMm1cKhCXgubmujWfziWLycEAO6wuoMg2XXH0LHRFlKVv6PMN8W2UDkEus3f+o8uj+J X-Received: by 10.224.73.137 with SMTP id q9mr21395429qaj.13.1377642813394; Tue, 27 Aug 2013 15:33:33 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id j11sm32437421qaa.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 15:33:32 -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: <521D2887.40502@cs.tcd.ie> Date: Tue, 27 Aug 2013 18:33:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> <521D2887.40502@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org, Henning Schulzrinne 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, 27 Aug 2013 22:33:42 -0000 But we have solved it well enough that commerce based on it works well = enough. It can be stymied by poor regulation, and it's not perfect, but it works = well enough to use. Brian On Aug 27, 2013, at 6:30 PM, Stephen Farrell = wrote: > On =FEri 27.=E1g=FA 2013 21:46, Brian Rosen wrote: >>=20 >> We'd have the same problem if they required Gaelic. But if the name = you assert is the same one you use with your bank, your car dealer and = your pizza parlor, then it will be given a decent score. > I was talking about Gaelige - you see the point is that once you = consider naming people, you get these kind of complexities. In the = specific case, Irish (Gaelige) is the first official language of Ireland = and that wins in all sorts of ways (e.g. street signs, our University = letterhead) and would likely win in this case too. So the putative PKI = or whatever would have to support Irish and other oddities of naming, = and I'm sure many other countries have their own fine oddities too;-) >=20 > All I'm saying is: this is complicated stuff and not simple and = claiming its a solved problem is not credible. >=20 > S. >=20 From stephen.farrell@cs.tcd.ie Tue Aug 27 15:43:12 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 0D3A311E80E3 for ; Tue, 27 Aug 2013 15:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.719 X-Spam-Level: X-Spam-Status: No, score=-103.719 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, GB_I_LETTER=-2, 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 ddDBeYdJ79Kq for ; Tue, 27 Aug 2013 15:43:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 171BB11E80D5 for ; Tue, 27 Aug 2013 15:43:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7DA2DBE5C; Tue, 27 Aug 2013 23:43:01 +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 dMwRh0dk23nq; Tue, 27 Aug 2013 23:43:00 +0100 (IST) Received: from [192.168.1.45] (nova006-184.cust-nat.nova.is [46.182.184.6]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 35989BE56; Tue, 27 Aug 2013 23:42:53 +0100 (IST) Message-ID: <521D2B64.2080505@cs.tcd.ie> Date: Tue, 27 Aug 2013 22:42:44 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> <521D2887.40502@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: cnit@ietf.org, Henning Schulzrinne 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, 27 Aug 2013 22:43:12 -0000 On þri 27.ágú 2013 22:33, Brian Rosen wrote: > But we have solved it well enough that commerce based on it works well enough. > > It can be stymied by poor regulation, and it's not perfect, but it works well enough to use. So I've no idea what we nor what solution you mean, nor within what scope that solution might work. Can you provide pointers? "Poor regulation" also seems trite - sure all regulators can do weird stuff, but you can't (I hope) claim that anything that your favourite regulator doesn't require is poor regulation, right? The world is just a bigger place than that. S. > > Brian > > On Aug 27, 2013, at 6:30 PM, Stephen Farrell wrote: > >> On þri 27.ágú 2013 21:46, Brian Rosen wrote: >>> We'd have the same problem if they required Gaelic. But if the name you assert is the same one you use with your bank, your car dealer and your pizza parlor, then it will be given a decent score. >> I was talking about Gaelige - you see the point is that once you consider naming people, you get these kind of complexities. In the specific case, Irish (Gaelige) is the first official language of Ireland and that wins in all sorts of ways (e.g. street signs, our University letterhead) and would likely win in this case too. So the putative PKI or whatever would have to support Irish and other oddities of naming, and I'm sure many other countries have their own fine oddities too;-) >> >> All I'm saying is: this is complicated stuff and not simple and claiming its a solved problem is not credible. >> >> S. >> From br@brianrosen.net Tue Aug 27 15:49: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 D889B11E821E for ; Tue, 27 Aug 2013 15:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.635, 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 kskMNutRW3EN for ; Tue, 27 Aug 2013 15:49:36 -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 D7C5311E81B5 for ; Tue, 27 Aug 2013 15:49:35 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 8so2312321qea.18 for ; Tue, 27 Aug 2013 15:49:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=k4UlnS92wmwtuTv31cnpxk8Rfr6Sj8Jrl7pVMUjOe2E=; b=LmS/ID9JZbzwJtZhouYLex+MVVsPUDOkuSr4qbJwVlEZPDuLhEtTCkezFAXffXP03v HH/+4uhOdoqdqMwQYOZHQ4kG2C0VWfuKjRh8tGKEc9FzRIMPnnAWgX2eMiQ9UqDVAmXT y59CmYnmfe8MSjbwrBL7ZWa52kjudiGadRC3U+V9KpwaOrzLiksZIUKqw/rzmWIlF5Df HIm/n+NLwWs8/QxIVtqpNkOMg5a9vE/Zdt4WRD8++I/3ohmQ8mdWX4DRursY+qBqOk8F fe9sMCTjttHUv3qiMlwUYEde20Lh/kbpkxubwbHOU9Ghsb8Ne4DshGJyeJy/WfYEaccI IAjA== X-Gm-Message-State: ALoCoQnKcH3b5Fp/7IDxE4B0Q1Z6j4f8Q8wR+QhBRXnqBW7w0o/jZ0ZnHKKXtUQwet8m8N/QiCKo X-Received: by 10.229.224.65 with SMTP id in1mr4238108qcb.17.1377643774273; Tue, 27 Aug 2013 15:49:34 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 9sm32538257qau.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 15:49:33 -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: <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> Date: Tue, 27 Aug 2013 18:49:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Alex Bobotek , "Dwight, Timothy M \(Tim\)" , Stephen Farrell , Henning Schulzrinne 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, 27 Aug 2013 22:49:42 -0000 We're proposing to change CNAM in a couple of ways: 1. We're proposing to move the name determination from the termination = to the origination 2. We're proposing to send a score=20 We think the score can be used very effectively by the termination. It = can be used with a threshold, and the threshold can be set by the = termination service provider to match what service level it offers. = More interestingly, it can be used by the termination device to display = some useful data to the consumer that is not black or white. We want the score to be as accurate as it can be. The databases have = dozens of fields, not all of which are populated for every record. The = more fields you provide, the more accurate the score is (and the higher = the score gets). If all you query with is name and phone number, the = confidence level is medium to low. If you have more data, like address = for example, the confidence is considerably higher. It's not that = address is better, it's that if you have a match of name AND number AND = address, you have a much smaller error. The databases we have today use scores. Just as an example, my company has such a database. It has dozens of = fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. The exact same database is used for a call center caller match query. = You call the call center, the operator asks your name and address, gets = phone number from ANI and they query the database (same database) to get = a score of how likely the data in the query matches (name and phone = number and address match each other). The service you get depends on = that score. We can provide a much better service if we have more information, and = the devices and services downstream can make use of score data to decide = how to present the call. Brian On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >=20 > On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >=20 >> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >=20 > Yes, I know they're queried on termination; and yes, I know they're = queried using the source telephone number. STIR will provide validity = for that source number, so that you can't pretend to be a source number = you aren't. That should make things better for calling names, if the = content of the calling name databases is accurate. You've been claiming = the content of the databases is fairly accurate. (and as far as I can = tell, they have been relatively accurate so far, for at least CNAM = databases though maybe not LIDB ones) >=20 > I know many folks don't like the CNAM model, but I believe they don't = like it due to the pricing model - not due to bad content, nor due to = having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >=20 > I don't know what you mean by "that gets poor scores". As far as I = know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >=20 >=20 >> What we need is to do the dip at the origination side, where you have = more information to make the score larger, and securely carry it in the = SIP signaling. That is the problem to be solved - I have the name, the = score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >=20 > I think that jumps to a solution - presumably the problem is "calling = names aren't reliable"; the problem is not "we can't send scores = securely in SIP". >=20 > This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: > draft-wing-sipping-spam-score > draft-schwartz-sipping-spit-saml >=20 > -hadriel >=20 From hadriel.kaplan@oracle.com Tue Aug 27 15:53: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 DA4FA11E8385 for ; Tue, 27 Aug 2013 15:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.52 X-Spam-Level: X-Spam-Status: No, score=-7.52 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, GB_I_LETTER=-2, 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 OOx5-D7lZ3Fp for ; Tue, 27 Aug 2013 15:53:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5C32611E8245 for ; Tue, 27 Aug 2013 15:53:41 -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 r7RMrW8w032479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 22:53:33 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 r7RMrVY0016550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 22:53:31 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RMrUgs000632; Tue, 27 Aug 2013 22:53:30 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 15:53:30 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <521D2887.40502@cs.tcd.ie> Date: Tue, 27 Aug 2013 18:53:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <33FD6A9D-A381-4F41-93A4-47D2C5725963@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> <521D2887.40502@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: cnit@ietf.org, Henning Schulzrinne , 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: Tue, 27 Aug 2013 22:53:49 -0000 On Aug 27, 2013, at 6:30 PM, Stephen Farrell = wrote: > I was talking about Gaelige - you see the point is that once you = consider naming people, you get these kind of complexities. In the = specific case, Irish (Gaelige) is the first official language of Ireland = and that wins in all sorts of ways (e.g. street signs, our University = letterhead) and would likely win in this case too. So the putative PKI = or whatever would have to support Irish and other oddities of naming, = and I'm sure many other countries have their own fine oddities too;-) What do your phone calls display now? What do your printed phonebooks = list? =46rom a character encoding perspective we can encode anything in UTF-8. = =46rom a perspective of "I have two names", we can even carry two names = in SIP or put two or more names into a database (obviously). One question is which name should be displayed when you receive a call? = Is that up to the sender to decide, or the receiver to decide? = Regardless, we can have the SIP message indicate which one to display = but let the receiver pick a different one. Or if the sender gets to = decide, then just carry only one of the possible names to begin with, so = long as the receiver can validate that name is one of the ones the = sender is allowed to claim. I think the really hard part with any of this is how do we know the = sender can claim one (or more) names - i.e., who would receivers truly = trust to validate source names properly? > All I'm saying is: this is complicated stuff and not simple and = claiming its a solved problem is not credible. It's sorta "solved" in a way: email. It isn't solved in the sense that = the username is valid obviously, but I mean it's solved in the sense = that this email seems to have only one representation of your = display-name and your government didn't complain. ;) -hadriel From br@brianrosen.net Tue Aug 27 15:58: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 8A92811E821F for ; Tue, 27 Aug 2013 15:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.989 X-Spam-Level: X-Spam-Status: No, score=-103.989 tagged_above=-999 required=5 tests=[AWL=1.610, BAYES_00=-2.599, GB_I_LETTER=-2, 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 n9fpf4d81wiz for ; Tue, 27 Aug 2013 15:58:51 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 49E5221F9FDA for ; Tue, 27 Aug 2013 15:58:51 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id z10so3000786qcx.32 for ; Tue, 27 Aug 2013 15:58:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=sTF+go53hJbPVWS5PVSHFyYm+W2iSg50kX7edVUUyrE=; b=Gfj2A279VcFazOa9npn7uiVCZM7R/GnIORmUf6sNaGx2u8rqDe600RRd4A0Z/QmtzS U/9CNd6HgEzOc22+kTCgLOB1L6vtz2vgJEH6Im48qHMh+CjKxrv5cte/MKx5L3PrBMPM ltIwbluH9P+Gbpasx/ugBbWsUIlNtQJuZ0wMLNOEhViuvZcJCFkp/elClITjZNc6411r hSTMsoCZPTwSJozGt5ORSqwd8OwsH5rSiBskM9m2cKiPdv/o1fpNqTBYe/97V0hO/X1c qwlC5t89Wtx5CUHxT3WWqL0EnhRK7hgmSVL+UklelcCpYglCRm4DL7IxmK/ZA8DyX1VB uHSQ== X-Gm-Message-State: ALoCoQknNMxPRJqpKpa0zZ+y5JqBKNaLm09Kov1ec+eyyEtxjW9SSa1i4XlWeP6YwfU7h8ChGe61 X-Received: by 10.49.24.178 with SMTP id v18mr26917125qef.12.1377644330429; Tue, 27 Aug 2013 15:58:50 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 9sm32594323qau.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 15:58:49 -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: <521D2B64.2080505@cs.tcd.ie> Date: Tue, 27 Aug 2013 18:58:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6E5E0DCF-5E79-40DC-BB4D-173C45D02879@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> <521D2887.40502@cs.tcd.ie> <521D2B64.2080505@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org, Henning Schulzrinne 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, 27 Aug 2013 22:58:57 -0000 See the email I just sent to Hadriel for how these systems work. In the = U.S., there are maybe 5 or 6 such databases. They all have different = content, and for any given record, some of them will be more accurate = than the others, but they could all provide a service like what I = described. I don't know how many exist for Irish records, but I'd guess = it's more than one and less than 5 or 6. They exist in most developed = countries. It's always possible for the origination carrier to attempt to provide = the validation service itself. Depending on how it collects and = verifies data, it might be able to do the job acceptably well. The = scheme only works well if there are a relatively small number of = validators, where the trust level can reasonably be evaluated by the = termination SP (or other service). If every SP tried to do it = themselves, we probably would not have a workable system. If the regulator requires names be presented in Irish, but that form of = name is not commonly used in commercial transactions, unless there is a = reasonable way to translate, the mechanisms we have today would fail. = If the regulator requires something we can't do, then it is at least a = candidate for bad regulation. In my experience, regulators try not to = ask for the impossible, but sometimes, it happens anyway. Brian On Aug 27, 2013, at 6:42 PM, Stephen Farrell = wrote: > On =FEri 27.=E1g=FA 2013 22:33, Brian Rosen wrote: >> But we have solved it well enough that commerce based on it works = well enough. >>=20 >> It can be stymied by poor regulation, and it's not perfect, but it = works well enough to use. > So I've no idea what we nor what solution you mean, nor within what = scope that solution might work. Can you provide pointers? >=20 > "Poor regulation" also seems trite - sure all regulators can do weird = stuff, but you can't (I hope) claim that anything that your favourite = regulator doesn't require is poor regulation, right? The world is just a = bigger place than that. >=20 > S. >>=20 >> Brian >>=20 >> On Aug 27, 2013, at 6:30 PM, Stephen Farrell = wrote: >>=20 >>> On =FEri 27.=E1g=FA 2013 21:46, Brian Rosen wrote: >>>> We'd have the same problem if they required Gaelic. But if the = name you assert is the same one you use with your bank, your car dealer = and your pizza parlor, then it will be given a decent score. >>> I was talking about Gaelige - you see the point is that once you = consider naming people, you get these kind of complexities. In the = specific case, Irish (Gaelige) is the first official language of Ireland = and that wins in all sorts of ways (e.g. street signs, our University = letterhead) and would likely win in this case too. So the putative PKI = or whatever would have to support Irish and other oddities of naming, = and I'm sure many other countries have their own fine oddities too;-) >>>=20 >>> All I'm saying is: this is complicated stuff and not simple and = claiming its a solved problem is not credible. >>>=20 >>> S. >>>=20 >=20 From br@brianrosen.net Tue Aug 27 16:08:28 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 7F27E11E821E for ; Tue, 27 Aug 2013 16:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.051 X-Spam-Level: X-Spam-Status: No, score=-104.051 tagged_above=-999 required=5 tests=[AWL=1.548, BAYES_00=-2.599, GB_I_LETTER=-2, 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 lQhJCF8euS4a for ; Tue, 27 Aug 2013 16:08:22 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBB111E81EB for ; Tue, 27 Aug 2013 16:08:22 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so3002865qcw.16 for ; Tue, 27 Aug 2013 16:08:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ZaVAGNUgsWXZWjfe06f1WlDYTHrpc4wYvY42lsv3sx0=; b=RPnYNLfawikIMX/XmAKavpRy/2nt1mEn3EM2IHXD1v8+FrXggqFRTfawMPTKZ1Eoet zKqhnPqomoj09i+oUi4u1O9h8Hy0GC9ZRfuPTmSW4B18TVw99qd3rxb8h7wMK5YrnMSg GpmA1pW836Bj5vxvJImX0aicuClN78Wxy6Bo6xHsv8YMYXBloZxZnivyHvwNE5ARgJhP 5hNohJsacjTtKAJdnqkEDH7LGeO3axqGIwZzF1q9LApTajxDo71Y5XJ4uNq05lXUcF+k rbYCrx8go+hGXfBrRz7AaGHXe+ZVtQFRTcIQDMLmJb6Il1wbkmhEOixfCV/iq1LSE13J 4j6g== X-Gm-Message-State: ALoCoQl48IC98jrh0tPFOd8zjA48MMJ+C9VpxnBsBTrvjf2FO2fDeQhYLADd3BXwe+0IV2MMUkO5 X-Received: by 10.49.106.226 with SMTP id gx2mr18212056qeb.67.1377644893862; Tue, 27 Aug 2013 16:08:13 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id g3sm32648169qas.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 16:08:12 -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: <33FD6A9D-A381-4F41-93A4-47D2C5725963@oracle.com> Date: Tue, 27 Aug 2013 19:08:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1AF2FF9A-9277-4784-9622-A12056D0B973@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> <521D2887.40502@cs.tcd.ie> <33FD6A9D-A381-4F41-93A4-47D2C5725963@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org, Henning Schulzrinne , Stephen Farrell 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, 27 Aug 2013 23:08:28 -0000 Today, all we get is what we told the origination provider (or enter = into their UI for the examples Henning cited) or what we get from the = thresholded query to termination side CNAM dips that I described. I hope current UIs are not a limiting factor in this work. We have to = make POTS phones served by ATAs or SIP interconnects to Class 5 switches = work, but if smartphones have better UIs, we can make use of them. I've only thought about carrying one name. I'm not sure what the use = case for more than one is. Clearly, the receiver decides what to display. I would like the sender to send one name, with the score and validation = of that name. I agree that in order to work, there has to be only a small number of = validation services that the receiver can evaluate and decide what to = do. It's certainly conceivable that if it has a name validated by an = entity it does not know, or does not trust, it could do the kind of = termination query we have now. It could even send in the name it gets = (and the phone number) and get a better score than sending just the = number. Or, it could downgrade the score, or just display "unknown". email is not a good example. The display name typically has no = validation at all. It's more likely it's right if the domain is = ibm.com, and less likely if it's gmail.com, but in general, there is no = validation of display name in email. Brian On Aug 27, 2013, at 6:53 PM, Hadriel Kaplan = wrote: >=20 > On Aug 27, 2013, at 6:30 PM, Stephen Farrell = wrote: >=20 >> I was talking about Gaelige - you see the point is that once you = consider naming people, you get these kind of complexities. In the = specific case, Irish (Gaelige) is the first official language of Ireland = and that wins in all sorts of ways (e.g. street signs, our University = letterhead) and would likely win in this case too. So the putative PKI = or whatever would have to support Irish and other oddities of naming, = and I'm sure many other countries have their own fine oddities too;-) >=20 > What do your phone calls display now? What do your printed phonebooks = list? >=20 > =46rom a character encoding perspective we can encode anything in = UTF-8. =46rom a perspective of "I have two names", we can even carry = two names in SIP or put two or more names into a database (obviously). >=20 > One question is which name should be displayed when you receive a = call? Is that up to the sender to decide, or the receiver to decide? = Regardless, we can have the SIP message indicate which one to display = but let the receiver pick a different one. Or if the sender gets to = decide, then just carry only one of the possible names to begin with, so = long as the receiver can validate that name is one of the ones the = sender is allowed to claim. >=20 > I think the really hard part with any of this is how do we know the = sender can claim one (or more) names - i.e., who would receivers truly = trust to validate source names properly? >=20 >=20 >> All I'm saying is: this is complicated stuff and not simple and = claiming its a solved problem is not credible. >=20 > It's sorta "solved" in a way: email. It isn't solved in the sense = that the username is valid obviously, but I mean it's solved in the = sense that this email seems to have only one representation of your = display-name and your government didn't complain. ;) >=20 > -hadriel >=20 From Henning.Schulzrinne@fcc.gov Tue Aug 27 16:11: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 184C711E80F5 for ; Tue, 27 Aug 2013 16:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=1.190, BAYES_00=-2.599, GB_I_LETTER=-2] 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 CNJOPv20DsXG for ; Tue, 27 Aug 2013 16:11:02 -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 BAB5B11E80D7 for ; Tue, 27 Aug 2013 16:11:01 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Stephen Farrell' , Brian Rosen Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAAFJKoAAACcdwAAAYq7gAAAGqwAAABSjgAACDjfAA== Date: Tue, 27 Aug 2013 23:10:59 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> <521D2887.40502@cs.tcd.ie> <521D2B64.2080505@cs.tcd.ie> In-Reply-To: <521D2B64.2080505@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" 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, 27 Aug 2013 23:11:06 -0000 There are a fairly large number of entities that provide mostly-accurate in= formation about businesses. They are obviously country-specific, including = multiple language renderings (think Canada if China and Japan are too exoti= c). Well-known examples include Experian (for both businesses and consumers= ) and Dun & Bradstreet (for businesses; they provide the DUN which identifi= es every US business of non-trivial size). They often also provide credit i= nformation, but that's usually a separate product.=20 Random selection: http://www.experian.com/business-information/business-information-c.html?in= tcmp=3Dhptn_bis "The company's business database provides comprehensive, third-party-verifi= ed information on 99.9 percent of all U.S. companies." There are probably half a dozen similar outfits, with different business mo= dels. As an example, the FCC Video Relay Service Report & Order discusses validat= ion of key attributes (name, address, DOB) for potential users of that serv= ice, to reduce fraud. A number of entities have claimed that they provide s= uch services on a routine and large-scale basis today. They don't work 100%= of the time, i.e., some low-profile entities that haven't left much of a f= ootprint are hard to validate, but they mostly seem to work. Obviously, thi= s is even easier in countries with more established identity verification a= nd record keeping, such as most European countries. These databases are keyed on phone numbers, social security numbers, DUNs, = FEINs (Federal tax ID) or name matches. Besides rendering the information i= n a way that is meaningful to the recipient (UTF8 will do that...), the pre= cise accents on the name are immaterial for that process. As noted, in many cases, carriers, through their business relationships, kn= ow pretty well who their (large) customers are (i.e., their legally registe= red name) and what their DUN is. That's probably not as true for residentia= l customers. I think the scores that Brian is talking about are of two kinds: If a prosp= ective customer gets sent to one of those services, they try to ascertain w= hether the person they are talking to is really John Smith, as claimed, bas= ed on answering questions. (This is done either by phone or a web page.) If= the person doesn't have a whole lot of verifiable information ("who financ= ed your first car?" "where did you live in 1990?"), they get a lower confid= ence score. Obviously, for wireline service, the service provider is 100% s= ure where the customer lives, but may not have checked the name against the= driver's license. There may also be scores on the data record itself, but I haven't seen that= as much in practice. This is not a credit score, simply a "is this informa= tion likely reliable?" score. Thus, for a business, besides providing full information, you could imagine= that a carrier would certify "this call is from DUN 12345, I'm sure", and = then the recipient can look up the information. You can try this out by typing a business name at dnb.com -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Tuesday, August 27, 2013 6:43 PM To: Brian Rosen Cc: cnit@ietf.org; Henning Schulzrinne Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) On =FEri 27.=E1g=FA 2013 22:33, Brian Rosen wrote: > But we have solved it well enough that commerce based on it works well en= ough. > > It can be stymied by poor regulation, and it's not perfect, but it works = well enough to use. So I've no idea what we nor what solution you mean, nor within what scope t= hat solution might work. Can you provide pointers? "Poor regulation" also seems trite - sure all regulators can do weird stuff= , but you can't (I hope) claim that anything that your favourite regulator = doesn't require is poor regulation, right? The world is just a bigger place= than that. S. > > Brian > > On Aug 27, 2013, at 6:30 PM, Stephen Farrell = wrote: > >> On =FEri 27.=E1g=FA 2013 21:46, Brian Rosen wrote: >>> We'd have the same problem if they required Gaelic. But if the name yo= u assert is the same one you use with your bank, your car dealer and your p= izza parlor, then it will be given a decent score. >> I was talking about Gaelige - you see the point is that once you conside= r naming people, you get these kind of complexities. In the specific case, = Irish (Gaelige) is the first official language of Ireland and that wins in = all sorts of ways (e.g. street signs, our University letterhead) and would = likely win in this case too. So the putative PKI or whatever would have to = support Irish and other oddities of naming, and I'm sure many other countri= es have their own fine oddities too;-) >> >> All I'm saying is: this is complicated stuff and not simple and claiming= its a solved problem is not credible. >> >> S. >> From hadriel.kaplan@oracle.com Tue Aug 27 17:40:08 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 DBAA211E8237 for ; Tue, 27 Aug 2013 17:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 1VHPBxXpGEIj for ; Tue, 27 Aug 2013 17:40:02 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3458B11E8103 for ; Tue, 27 Aug 2013 17:39:57 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7S0diPV003751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Aug 2013 00:39:46 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7S0dgrB028457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 00:39:43 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7S0dgjo028449; Wed, 28 Aug 2013 00:39:42 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 17:39:42 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <6E5E0DCF-5E79-40DC-BB4D-173C45D02879@brianrosen.net> Date: Tue, 27 Aug 2013 20:39:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> <521D2887.40502@cs.tcd.ie> <521D2B64.2080505@cs.tcd.ie> <6E5E0DCF-5E79-40DC-BB4D-173C45D02879@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: cnit@ietf.org, Henning Schulzrinne , Stephen Farrell 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: Wed, 28 Aug 2013 00:40:09 -0000 On Aug 27, 2013, at 6:58 PM, Brian Rosen wrote: > See the email I just sent to Hadriel for how these systems work. In = the U.S., there are maybe 5 or 6 such databases. =20 Actually I've been told there are over a dozen CNAM providers just in = the US. And over a dozen LIDB too (some are the same company as the = CNAM, some not). I do agree there are only a handful of "big" ones. > It's always possible for the origination carrier to attempt to provide = the validation service itself. Depending on how it collects and = verifies data, it might be able to do the job acceptably well. The = scheme only works well if there are a relatively small number of = validators, where the trust level can reasonably be evaluated by the = termination SP (or other service). If every SP tried to do it = themselves, we probably would not have a workable system. It's worse than that. It just reverts back to the problems for how we = got to STIR. It also reverts back to the discussion of why doing a = web-pki model for calling numbers wouldn't work in the long run, and I = don't see a reason to think a web-pki model will work for calling names = any more than numbers. > If the regulator requires names be presented in Irish, but that form = of name is not commonly used in commercial transactions, unless there is = a reasonable way to translate, the mechanisms we have today would fail. = If the regulator requires something we can't do, then it is at least a = candidate for bad regulation. In my experience, regulators try not to = ask for the impossible, but sometimes, it happens anyway. [It's not germane to this discussion, but as an aside I find some = regulators do indeed ask for the impossible, either on purpose (to = protect commercial interests of specific companies in their country), or = because they don't have technical expertise in the specific areas they = regulate. But that's a topic for another day.] -hadriel From hadriel.kaplan@oracle.com Tue Aug 27 18:12: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 24A4421E8115 for ; Tue, 27 Aug 2013 18:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 fIbfjOFCJHAo for ; Tue, 27 Aug 2013 18:12:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id F1BB121E8113 for ; Tue, 27 Aug 2013 18:12:09 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7S1C1aC008476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Aug 2013 01:12:02 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 r7S1BwUS025828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 01:11:59 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 r7S1BvlW015546; Wed, 28 Aug 2013 01:11:58 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 18:11:57 -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: <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> Date: Tue, 27 Aug 2013 21:11:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38C03DC1-C8CF-4C7A-9BE5-34A2169C2913@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Henning Schulzrinne , "cnit@ietf.org" , Alex Bobotek , "Dwight, Timothy M \(Tim\)" , Stephen Farrell 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: Wed, 28 Aug 2013 01:12:16 -0000 Ignore the score thing for a minute - I think it's crazy to rely on the = sender's notion of a validity score (and that's not how spam score = systems work, for example) - but ignore that for now. Let's just talk about this need to sign the stuff in the INVITE. I = think we must be talking past each other somehow. Either I'm missing = something, or you are, or both. :) What is it you think you're gaining by having the validation service's = "package" signed by STIR? Or maybe my disconnect is more basic than that - what exactly is in the = "package"? You don't have to describe every possible field, but let's = just say an absolutely plain/simplest package possible: what's in it? -hadriel On Aug 27, 2013, at 6:49 PM, Brian Rosen wrote: > We're proposing to change CNAM in a couple of ways: > 1. We're proposing to move the name determination from the termination = to the origination > 2. We're proposing to send a score=20 >=20 > We think the score can be used very effectively by the termination. = It can be used with a threshold, and the threshold can be set by the = termination service provider to match what service level it offers. = More interestingly, it can be used by the termination device to display = some useful data to the consumer that is not black or white. >=20 > We want the score to be as accurate as it can be. The databases have = dozens of fields, not all of which are populated for every record. The = more fields you provide, the more accurate the score is (and the higher = the score gets). If all you query with is name and phone number, the = confidence level is medium to low. If you have more data, like address = for example, the confidence is considerably higher. It's not that = address is better, it's that if you have a match of name AND number AND = address, you have a much smaller error. >=20 > The databases we have today use scores. >=20 > Just as an example, my company has such a database. It has dozens of = fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. >=20 > The exact same database is used for a call center caller match query. = You call the call center, the operator asks your name and address, gets = phone number from ANI and they query the database (same database) to get = a score of how likely the data in the query matches (name and phone = number and address match each other). The service you get depends on = that score. >=20 > We can provide a much better service if we have more information, and = the devices and services downstream can make use of score data to decide = how to present the call. >=20 > Brian >=20 > On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>=20 >>> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>=20 >> Yes, I know they're queried on termination; and yes, I know they're = queried using the source telephone number. STIR will provide validity = for that source number, so that you can't pretend to be a source number = you aren't. That should make things better for calling names, if the = content of the calling name databases is accurate. You've been claiming = the content of the databases is fairly accurate. (and as far as I can = tell, they have been relatively accurate so far, for at least CNAM = databases though maybe not LIDB ones) >>=20 >> I know many folks don't like the CNAM model, but I believe they don't = like it due to the pricing model - not due to bad content, nor due to = having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>=20 >> I don't know what you mean by "that gets poor scores". As far as I = know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >>=20 >>=20 >>> What we need is to do the dip at the origination side, where you = have more information to make the score larger, and securely carry it in = the SIP signaling. That is the problem to be solved - I have the name, = the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>=20 >> I think that jumps to a solution - presumably the problem is "calling = names aren't reliable"; the problem is not "we can't send scores = securely in SIP". >>=20 >> This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: >> draft-wing-sipping-spam-score >> draft-schwartz-sipping-spit-saml >>=20 >> -hadriel >>=20 >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From pkyzivat@alum.mit.edu Tue Aug 27 18:35: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 9982621E8105 for ; Tue, 27 Aug 2013 18:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.124, 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 SuGvV2B2b1SS for ; Tue, 27 Aug 2013 18:35:29 -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 B8F5821E80F4 for ; Tue, 27 Aug 2013 18:35:28 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id HzYa1m00816LCl0551bNxP; Wed, 28 Aug 2013 01:35:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id J1bM1m0163ZTu2S3S1bNGC; Wed, 28 Aug 2013 01:35:22 +0000 Message-ID: <521D53D9.2080008@alum.mit.edu> Date: Tue, 27 Aug 2013 21:35:21 -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: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> In-Reply-To: <9767A883-6957-4AEA-9F3C-77B270EE13CD@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=1377653722; bh=8nKCLCahVSuiwTxFiJcbEsZ2gsrOKFuk6vfhfVdH6/E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eLKRukis16/ht/Y+kYh8w65hzIwZpQqoBIHaIoS+A3XFThz9gRDi2eV0JTAg3djKw B4vAOt6sTy+SeJ+ZFByynvZnqIs9ioBveTZyfMqJUnBQHmMkKKqqnm7o0ddy4fcilx WTZ/EcQZizUEYbOFIOyChl1ev+2HHYUg9wYmVXAdhEKeZrQ5w7v69VjE/UHO6zJn3C FUtFkB2NCMtcvCXCynLLgrSJIhlFgAjHw2n/8Q5JckPQ9xtG2b4rnwHyKoO+PbMvlz C2DDC/mJe+3Eu/H3RuIr+jdjYCHaYyRwFu5YHhl9LrGvh++s/yOjtoxJeUm91PDfCG VihtF+fsbBRew== 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: Wed, 28 Aug 2013 01:35:34 -0000 Brian, Like Hadriel, I'm not getting your point about the score, and what having a bunch of factors says about the score. I can see that if I'm trying to enroll with some naming service that they would want to get a bunch of facts from me to verify I am who I say I am. And if I have less facts then they are less certain who I am. That could enter into a score they give when queried. But I don't see what that has to do with this problem. One possibility is that the originator of the call always uses one name per phone number, in which case getting the name by looking up the phone number is fine. In that case, the score depends on what facts were given when the name was assigned to the number in the db. The lookup can be done by the recipient without loss of function. Another possibility is that the originator wants the option of using multiple names with the same number. (One for any given call.) For that to work, I guess all the possible names for a number must be enrolled. And presumably each of them get a score. In this case the phone number isn't sufficient to lookup the name. But the caller could include the name in the signaling, and the recipient could provide both the name and number for lookup. Then I would succeed, with a score, if that is one of the enrolled names for the number. Else it would fail. Another possibility is that signing of names is entirely independent of the signing of numbers, with possibly different entities doing it. In that case I agree that the recipient looking up the number won't give the same result. This seems something like a SAML system. Thanks, Paul On 8/27/13 6:49 PM, Brian Rosen wrote: > We're proposing to change CNAM in a couple of ways: > 1. We're proposing to move the name determination from the termination to the origination > 2. We're proposing to send a score > > We think the score can be used very effectively by the termination. It can be used with a threshold, and the threshold can be set by the termination service provider to match what service level it offers. More interestingly, it can be used by the termination device to display some useful data to the consumer that is not black or white. > > We want the score to be as accurate as it can be. The databases have dozens of fields, not all of which are populated for every record. The more fields you provide, the more accurate the score is (and the higher the score gets). If all you query with is name and phone number, the confidence level is medium to low. If you have more data, like address for example, the confidence is considerably higher. It's not that address is better, it's that if you have a match of name AND number AND address, you have a much smaller error. > > The databases we have today use scores. > > Just as an example, my company has such a database. It has dozens of fields. One of the products that is driven by the database is a CNAM service. When the termination side dips the database, it does so only with the telephone number. The scores are fairly low, but there is a threshold (I don't actually know the details). You get a name, or no entry found out of that dip. The database scores the data and applies a threshold to it. > > The exact same database is used for a call center caller match query. You call the call center, the operator asks your name and address, gets phone number from ANI and they query the database (same database) to get a score of how likely the data in the query matches (name and phone number and address match each other). The service you get depends on that score. > > We can provide a much better service if we have more information, and the devices and services downstream can make use of score data to decide how to present the call. > > Brian > > On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan wrote: > >> >> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >> >>> As I keep saying, over and over, what they are used for today is termination dips, where all you have to query with is the telephone number, and that gets poor scores. >> >> Yes, I know they're queried on termination; and yes, I know they're queried using the source telephone number. STIR will provide validity for that source number, so that you can't pretend to be a source number you aren't. That should make things better for calling names, if the content of the calling name databases is accurate. You've been claiming the content of the databases is fairly accurate. (and as far as I can tell, they have been relatively accurate so far, for at least CNAM databases though maybe not LIDB ones) >> >> I know many folks don't like the CNAM model, but I believe they don't like it due to the pricing model - not due to bad content, nor due to having to physically query it. They don't like the fact that the receiver of calls has to pay extra for getting data the far-end wanted to be delivered to begin with. >> >> I don't know what you mean by "that gets poor scores". As far as I know, there is no such thing as a "score" in the existing PSTN calling name market. There are name/number/phone-service "types" or category, but not scores of name accuracy afaik. Are there such things? Why would anyone claim their score is anything but perfect? >> >> >>> What we need is to do the dip at the origination side, where you have more information to make the score larger, and securely carry it in the SIP signaling. That is the problem to be solved - I have the name, the score, and the identity of the validator. I have to get that information across reliably, and reliably includes preventing messing with it at the origination side (so the sender can't lie about the score). >> >> I think that jumps to a solution - presumably the problem is "calling names aren't reliable"; the problem is not "we can't send scores securely in SIP". >> >> This whole topic is reminiscent of the debates the SIPPING WG had years ago on: >> draft-wing-sipping-spam-score >> draft-schwartz-sipping-spit-saml >> >> -hadriel >> > > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > From alex@bobotek.net Tue Aug 27 23:02: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 49C4211E8137 for ; Tue, 27 Aug 2013 23:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 3z2XdiyREhSG for ; Tue, 27 Aug 2013 23:02:51 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 7030611E810C for ; Tue, 27 Aug 2013 23:02:50 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta15.emeryville.ca.mail.comcast.net with comcast id J62F1m0041zF43QAF62qse; Wed, 28 Aug 2013 06:02:50 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta24.emeryville.ca.mail.comcast.net with comcast id J62o1m0034EJ4tY8k62oqJ; Wed, 28 Aug 2013 06:02:50 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Tue, 27 Aug 2013 22:55:06 -0700 From: Alex Bobotek To: Brian Rosen , Hadriel Kaplan Date: Tue, 27 Aug 2013 22:55:06 -0700 Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6jdqEnt2Kjif7cTrS3fDN6I7N3RQALR7kA Message-ID: <4B1956260CD29F4A9622F00322FE053193812973DF@BOBO1A.bobotek.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> In-Reply-To: <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377669770; bh=QrSan9HlrdhJ+dlqabHeyGm9U0CjjrUGmb7Ti046vMw=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=TyCC026h/r38rbEnPmUL5L3C76KWFHJo4O5walTYx38ZqStJfwI3Dbfx8QkucHi7S ezeKPNorqDZpxa6pgR/VhvXCExzEfoAt8ckO3BBbejd28c2vj6xwtyaJFUhfl7RpZh ZDh4cxsF81WYjcmn5w/L7Yx82lv3m8N/V4WXs5oA6TRHU10SRl+wMLh6nD9Y1GfrKt NyIQKn2OAkOaZnqpq+oETxHxQ59B1FNUYyIjW4Vi3OHnjo9kKserSXwQfkjbD2cyvx nyFOoOYaEiiMy4NF1eaPO47BUFoHf4gAEwF5o6UW+/sxPru6rnkHN2rhCmDM6dSnDF SytS6c6e8eUJQ== Cc: "cnit@ietf.org" , Stephen Farrell , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne 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: Wed, 28 Aug 2013 06:02:57 -0000 The points that the originating service provider should be presenting and p= ossibly signing the display name I accept as generally positive. The orig= inating service provider is usually in the best position to provide this in= formation. And if some notion of originator reputation (e.g., 'score') is = also presented and signed by the originating service provider, great. =20 A display name service cannot provide an adequate basis for trust for sever= al reasons:=20 1. Linear unstructured text naming cannot prevent fooling the recipient. = If an attacker wants to have their display name be Charlotte C Union and vi= sh, smish or phish Charlotte Credit Union's customers, they may. What migh= t be Ms. Charlotte's 'personal' calls shouldn't be blocked. =20 2. Further, even a perfect taxonomy of caller types (bank, person, ...)tha= t tells a called party that the caller is a person rather than a bank woul= d offer inadequate protection to vulnerable (e.g., permanently or temporari= ly disabled) individuals. Criminals are creative and will always find ways= to exploit the vulnerable with naming similarities. Nor could it, at leas= t without global adoption of identity authentication and registration requi= rements such as India's, be counted on to indicate telemarketing. I do not= see how a practical role-based naming taxonomy could be comprehensive enou= gh to prevent these exploits, but my ears are open if someone could point m= e to such an explanation. =20 3. We cannot assume that all originating service providers will be trustwo= rthy or even well intentioned. The opening of the service provider market = is increasing access to both reputable and disreputable parties. Display N= ames provided/signed only by an originating service provider should not be = trusted more than the service provider itself. =20 Given unique authenticated identities of the calling party and originating = service provider, reputation-based systems incorporating called party feedb= ack and calling pattern analysis can and are currently being used successfu= lly in some telephony applications (e.g., text messaging) to pressure peer = service providers to police their originations and originating parties, as = well as block calls from disreputable callers and, if necessary, disreputa= ble service providers. In much more heavily abused communications media (i= .e., email), reputation does the heavy lifting. =20 We need notions of service provider and originator reputation to control se= veral types of abuse such as vishing and smishing that authenticated names = cannot adequately mitigate. Called party Display Name is beneficial, but i= nsufficient. =20 It appears to me the 'score' Brian mentions is one notion of reputation. B= ut it's only one, and IMHO reputation needs much more extensive discussion.= =20 Personally, I believe that the telephony security framework should include = the following: * Authenticated identity (phone number) * Display name * Reputation framework that can be used to filter calls and indicate trust,= =20 and possibly an * Authorization framework that can be used to prove authority to use (e.g.,= by a fundraising boiler room or integrated messaging system) a particular = identity. Regards, Alex -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, August 27, 2013 3:50 PM To: Hadriel Kaplan Cc: Henning Schulzrinne; cnit@ietf.org; Alex Bobotek; Dwight, Timothy M (Ti= m); Stephen Farrell Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) We're proposing to change CNAM in a couple of ways: 1. We're proposing to move the name determination from the termination to t= he origination 2. We're proposing to send a score=20 We think the score can be used very effectively by the termination. It can= be used with a threshold, and the threshold can be set by the termination = service provider to match what service level it offers. More interestingly= , it can be used by the termination device to display some useful data to t= he consumer that is not black or white. We want the score to be as accurate as it can be. The databases have dozen= s of fields, not all of which are populated for every record. The more fie= lds you provide, the more accurate the score is (and the higher the score g= ets). If all you query with is name and phone number, the confidence level= is medium to low. If you have more data, like address for example, the co= nfidence is considerably higher. It's not that address is better, it's tha= t if you have a match of name AND number AND address, you have a much small= er error. The databases we have today use scores. Just as an example, my company has such a database. It has dozens of field= s. One of the products that is driven by the database is a CNAM service. = When the termination side dips the database, it does so only with the telep= hone number. The scores are fairly low, but there is a threshold (I don't= actually know the details). You get a name, or no entry found out of that= dip. The database scores the data and applies a threshold to it. The exact same database is used for a call center caller match query. You = call the call center, the operator asks your name and address, gets phone n= umber from ANI and they query the database (same database) to get a score o= f how likely the data in the query matches (name and phone number and addre= ss match each other). The service you get depends on that score. We can provide a much better service if we have more information, and the d= evices and services downstream can make use of score data to decide how to = present the call. Brian On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan wro= te: >=20 > On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >=20 >> As I keep saying, over and over, what they are used for today is termina= tion dips, where all you have to query with is the telephone number, and th= at gets poor scores. >=20 > Yes, I know they're queried on termination; and yes, I know they're=20 > queried using the source telephone number. STIR will provide validity=20 > for that source number, so that you can't pretend to be a source=20 > number you aren't. That should make things better for calling names,=20 > if the content of the calling name databases is accurate. You've been=20 > claiming the content of the databases is fairly accurate. (and as far=20 > as I can tell, they have been relatively accurate so far, for at least=20 > CNAM databases though maybe not LIDB ones) >=20 > I know many folks don't like the CNAM model, but I believe they don't lik= e it due to the pricing model - not due to bad content, nor due to having t= o physically query it. They don't like the fact that the receiver of calls= has to pay extra for getting data the far-end wanted to be delivered to be= gin with. >=20 > I don't know what you mean by "that gets poor scores". As far as I know,= there is no such thing as a "score" in the existing PSTN calling name mark= et. There are name/number/phone-service "types" or category, but not score= s of name accuracy afaik. Are there such things? Why would anyone claim t= heir score is anything but perfect? >=20 >=20 >> What we need is to do the dip at the origination side, where you have mo= re information to make the score larger, and securely carry it in the SIP s= ignaling. That is the problem to be solved - I have the name, the score, a= nd the identity of the validator. I have to get that information across re= liably, and reliably includes preventing messing with it at the origination= side (so the sender can't lie about the score). >=20 > I think that jumps to a solution - presumably the problem is "calling nam= es aren't reliable"; the problem is not "we can't send scores securely in S= IP". >=20 > This whole topic is reminiscent of the debates the SIPPING WG had years a= go on: > draft-wing-sipping-spam-score > draft-schwartz-sipping-spit-saml >=20 > -hadriel >=20 From hadriel.kaplan@oracle.com Wed Aug 28 06:02:52 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 1B29C21E804E for ; Wed, 28 Aug 2013 06:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Gvy7i9BRBRwb for ; Wed, 28 Aug 2013 06:02:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id EA93B21F9FE3 for ; Wed, 28 Aug 2013 06:02:44 -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 r7SD2ZKa020783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Aug 2013 13:02:35 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7SD2Vxv025865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 13:02:32 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7SD2VPL004819; Wed, 28 Aug 2013 13:02:31 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Aug 2013 06:02:30 -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: <4B1956260CD29F4A9622F00322FE053193812973DF@BOBO1A.bobotek.net> Date: Wed, 28 Aug 2013 09:02:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> <4B1956260CD29F4A9622F00322FE053193812973DF@BOBO1A.bobotek.net> To: Alex Bobotek X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "cnit@ietf.org" , Henning Schulzrinne , "Dwight, Timothy M \(Tim\)" , Stephen Farrell , 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: Wed, 28 Aug 2013 13:02:52 -0000 Unfortunately your point-3 is the problem: we know that some originating = "service providers" cannot be trusted. Some of them are just lazy or = understaffed; but some of them are actually complicit: letting their = customers generate unverified and unverifiable calling numbers and names = is actually part of their business model. That's the same problem that is making us do STIR to begin with. If we = could trust all originating service providers, or even thought that = reputation of originating providers alone was sufficient, we wouldn't = need half of the stuff STIR is defining. For example we could have = simply implement draft-kaplan-sip-asserter-identity, which was far = simpler than STIR will be. That would have enabled creating reputation = services to weed out bad originating service providers. But when I talked to some of the carriers about doing that, they had = concerns over the notion of deciding an entire originating service = provider was untrustworthy; concerns regarding lawsuits from those = originating providers, threshold level issues, and big problems if it = was used for international calls. The thing they liked about STIR was = it would be easily and legally defensible, including at an international = level. -hadriel On Aug 28, 2013, at 1:55 AM, Alex Bobotek wrote: > The points that the originating service provider should be presenting = and possibly signing the display name I accept as generally positive. = The originating service provider is usually in the best position to = provide this information. And if some notion of originator reputation = (e.g., 'score') is also presented and signed by the originating service = provider, great. =20 >=20 > A display name service cannot provide an adequate basis for trust for = several reasons:=20 >=20 > 1. Linear unstructured text naming cannot prevent fooling the = recipient. If an attacker wants to have their display name be Charlotte = C Union and vish, smish or phish Charlotte Credit Union's customers, = they may. What might be Ms. Charlotte's 'personal' calls shouldn't be = blocked. =20 >=20 > 2. Further, even a perfect taxonomy of caller types (bank, person, = ...)that tells a called party that the caller is a person rather than a = bank would offer inadequate protection to vulnerable (e.g., permanently = or temporarily disabled) individuals. Criminals are creative and will = always find ways to exploit the vulnerable with naming similarities. = Nor could it, at least without global adoption of identity = authentication and registration requirements such as India's, be counted = on to indicate telemarketing. I do not see how a practical role-based = naming taxonomy could be comprehensive enough to prevent these exploits, = but my ears are open if someone could point me to such an explanation. =20= >=20 > 3. We cannot assume that all originating service providers will be = trustworthy or even well intentioned. The opening of the service = provider market is increasing access to both reputable and disreputable = parties. Display Names provided/signed only by an originating service = provider should not be trusted more than the service provider itself. =20= >=20 > Given unique authenticated identities of the calling party and = originating service provider, reputation-based systems incorporating = called party feedback and calling pattern analysis can and are currently = being used successfully in some telephony applications (e.g., text = messaging) to pressure peer service providers to police their = originations and originating parties, as well as block calls from = disreputable callers and, if necessary, disreputable service providers. = In much more heavily abused communications media (i.e., email), = reputation does the heavy lifting. =20 >=20 > We need notions of service provider and originator reputation to = control several types of abuse such as vishing and smishing that = authenticated names cannot adequately mitigate. Called party Display = Name is beneficial, but insufficient. =20 >=20 > It appears to me the 'score' Brian mentions is one notion of = reputation. But it's only one, and IMHO reputation needs much more = extensive discussion. =20 >=20 > Personally, I believe that the telephony security framework should = include the following: >=20 > * Authenticated identity (phone number) > * Display name > * Reputation framework that can be used to filter calls and indicate = trust,=20 >=20 > and possibly an >=20 > * Authorization framework that can be used to prove authority to use = (e.g., by a fundraising boiler room or integrated messaging system) a = particular identity. >=20 >=20 > Regards, >=20 > Alex >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, August 27, 2013 3:50 PM > To: Hadriel Kaplan > Cc: Henning Schulzrinne; cnit@ietf.org; Alex Bobotek; Dwight, Timothy = M (Tim); Stephen Farrell > Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual = caller ID) >=20 > We're proposing to change CNAM in a couple of ways: > 1. We're proposing to move the name determination from the termination = to the origination 2. We're proposing to send a score=20 >=20 > We think the score can be used very effectively by the termination. = It can be used with a threshold, and the threshold can be set by the = termination service provider to match what service level it offers. = More interestingly, it can be used by the termination device to display = some useful data to the consumer that is not black or white. >=20 > We want the score to be as accurate as it can be. The databases have = dozens of fields, not all of which are populated for every record. The = more fields you provide, the more accurate the score is (and the higher = the score gets). If all you query with is name and phone number, the = confidence level is medium to low. If you have more data, like address = for example, the confidence is considerably higher. It's not that = address is better, it's that if you have a match of name AND number AND = address, you have a much smaller error. >=20 > The databases we have today use scores. >=20 > Just as an example, my company has such a database. It has dozens of = fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. >=20 > The exact same database is used for a call center caller match query. = You call the call center, the operator asks your name and address, gets = phone number from ANI and they query the database (same database) to get = a score of how likely the data in the query matches (name and phone = number and address match each other). The service you get depends on = that score. >=20 > We can provide a much better service if we have more information, and = the devices and services downstream can make use of score data to decide = how to present the call. >=20 > Brian >=20 > On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>=20 >>> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>=20 >> Yes, I know they're queried on termination; and yes, I know they're=20= >> queried using the source telephone number. STIR will provide = validity=20 >> for that source number, so that you can't pretend to be a source=20 >> number you aren't. That should make things better for calling names,=20= >> if the content of the calling name databases is accurate. You've = been=20 >> claiming the content of the databases is fairly accurate. (and as far=20= >> as I can tell, they have been relatively accurate so far, for at = least=20 >> CNAM databases though maybe not LIDB ones) >>=20 >> I know many folks don't like the CNAM model, but I believe they don't = like it due to the pricing model - not due to bad content, nor due to = having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>=20 >> I don't know what you mean by "that gets poor scores". As far as I = know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >>=20 >>=20 >>> What we need is to do the dip at the origination side, where you = have more information to make the score larger, and securely carry it in = the SIP signaling. That is the problem to be solved - I have the name, = the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>=20 >> I think that jumps to a solution - presumably the problem is "calling = names aren't reliable"; the problem is not "we can't send scores = securely in SIP". >>=20 >> This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: >> draft-wing-sipping-spam-score >> draft-schwartz-sipping-spit-saml >>=20 >> -hadriel >>=20 >=20 From br@brianrosen.net Wed Aug 28 06:29:21 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 49A7721F908F for ; Wed, 28 Aug 2013 06:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.108 X-Spam-Level: X-Spam-Status: No, score=-103.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 sD3hc9Qd8kel for ; Wed, 28 Aug 2013 06:29:06 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3F94611E8195 for ; Wed, 28 Aug 2013 06:29:06 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id eh20so6700306obb.15 for ; Wed, 28 Aug 2013 06:29:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=jD83iD1JROysy6iexYOepnWmMZH82zzch6mE1NsNCVs=; b=HB1cZ/FtKanf+RB3adYpDaNPq/liAepOFBgOjStYz6c5NCAsA+UmDin9SGw5cOcPN4 7JBbpz8iJzFsdC9LdrK9UPrJm+ulWMBslEQz3LXi5L6/AfAE+IiZEX6WmyNR/iS1yvBN SvBejNKnulJO68Vmtr91a59O7K9TYLqUTdgCADgpWAyDTbxASajaTIjRmYZy3GY484qB lE4DK+ov/di/nxwlc5aXJeQb4UjJtkbXuQ0n4ZGc5/HOfdsGqaAvLuX15U9aU1sujruB 7+gBaOzBnAPyzanOeJxAHSQxmwjp3HeAe+4D9wUJzjdGEAMSuoTA9CTeaZdg9MGD60D/ n3vw== X-Gm-Message-State: ALoCoQmhEMvnCrcHFUUp8nTdFV/Ha+7Ucc+Y+Q8n7zcla6YPdft+5CXTIbmtA/8mGxeLjTIYzykV X-Received: by 10.182.230.163 with SMTP id sz3mr6269187obc.81.1377696545772; Wed, 28 Aug 2013 06:29:05 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id qi5sm25821253obb.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 06:29:04 -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: Date: Wed, 28 Aug 2013 09:29:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <521D1A14.5080708@cs.tcd.ie> <521D2887.40502@cs.tcd.ie> <521D2B64.2080505@cs.tcd.ie> <6E5E0DCF-5E79-40DC-BB4D-173C45D02879@brianrosen.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org, Henning Schulzrinne , Stephen Farrell 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: Wed, 28 Aug 2013 13:29:21 -0000 Inline please On Aug 27, 2013, at 8:39 PM, Hadriel Kaplan = wrote: >=20 > On Aug 27, 2013, at 6:58 PM, Brian Rosen wrote: >=20 >> See the email I just sent to Hadriel for how these systems work. In = the U.S., there are maybe 5 or 6 such databases. =20 >=20 > Actually I've been told there are over a dozen CNAM providers just in = the US. And over a dozen LIDB too (some are the same company as the = CNAM, some not). I do agree there are only a handful of "big" ones. Most of these are NOT the databases I'm talking about. The classical LIDB does not have much validation, and some of them have = none. Those only have name and number. What I'm talking about has = 50-70 fields for each record. At least one of them is used as a CNAM = database, but they are usually used for web or call center commercial = transactions. There reason for existence is to validate data, not to = supply a name given a telephone number. Many of them, in normal = circumstances, don't give out field contents. They simply give a score = to set of data presented to them, where the score is a confidence index = of how likely the information presented is accurate and refers to the = same entity. I'm not opposed to a carrier operating a database, but the trust that a = recipient places in the data may be pretty low unless it mimics what the = commercial systems do. >=20 >=20 >> It's always possible for the origination carrier to attempt to = provide the validation service itself. Depending on how it collects and = verifies data, it might be able to do the job acceptably well. The = scheme only works well if there are a relatively small number of = validators, where the trust level can reasonably be evaluated by the = termination SP (or other service). If every SP tried to do it = themselves, we probably would not have a workable system. >=20 > It's worse than that. It just reverts back to the problems for how we = got to STIR. It also reverts back to the discussion of why doing a = web-pki model for calling numbers wouldn't work in the long run, and I = don't see a reason to think a web-pki model will work for calling names = any more than numbers. Not arguing. However, this is all a confidence discussion - how confident are you = that the name is accurate. In the current LIDB, for some carriers, there is zero confidence, = because there is zero validation. For some of the larger carriers, = there is some validation, but usually it's pretty minimal. Where the = termination SP uses the validation databases, rather than querying the = origination provider's LIDB, it doesn't matter how much validation the = originating carrier provides, because the termination carrier does't use = it. However, the validation database can't be really accurate (that is, = the score for the data it is supplying isn't very high) because all it = has to query with is the phone number, and the way these systems work, = if you only have one input factor, confidence is fairly low. On the other hand, if you queried that same database with both the = number AND the display name carried in the signaling, you would get a = higher confidence, even if the name was believed to be invalid. The = score would be low (score represents likelihood the data is consistent = with an actual entity) for a believed-to-be-invalid name, but the = underlying confidence in the data would be higher than querying with = just the phone number. I'm NOT advocating any sort of PKI here. Just a relatively small number = of validators whose trust can be assessed (independently) by the = termination. The credentials for the validators could be well known. >=20 >=20 >> If the regulator requires names be presented in Irish, but that form = of name is not commonly used in commercial transactions, unless there is = a reasonable way to translate, the mechanisms we have today would fail. = If the regulator requires something we can't do, then it is at least a = candidate for bad regulation. In my experience, regulators try not to = ask for the impossible, but sometimes, it happens anyway. >=20 > [It's not germane to this discussion, but as an aside I find some = regulators do indeed ask for the impossible, either on purpose (to = protect commercial interests of specific companies in their country), or = because they don't have technical expertise in the specific areas they = regulate. But that's a topic for another day.] >=20 > -hadriel >=20 From Henning.Schulzrinne@fcc.gov Wed Aug 28 06:29: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 7EDF121F9BB1 for ; Wed, 28 Aug 2013 06:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 j7Tb3tQ+cWvK for ; Wed, 28 Aug 2013 06:29: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 477FB21F9C00 for ; Wed, 28 Aug 2013 06:29:42 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Alex Bobotek' , Brian Rosen Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAADT0cAAAAyOIAAA4HxgAAA8nIAAA7c3AAAB0/OcA== Date: Wed, 28 Aug 2013 13:29:41 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> <4B1956260CD29F4A9622F00322FE053193812973DF@BOBO1A.bobotek.net> In-Reply-To: <4B1956260CD29F4A9622F00322FE053193812973DF@BOBO1A.bobotek.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" 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: Wed, 28 Aug 2013 13:29:47 -0000 Quick comments (not just on the message below): - I don't think either Brian or I are talking about LIDB/CNAM providers as = of today, although they may obviously overlap. If you actually take a look = at the real-world examples I provided, you'll notice that they have nothing= to do with CNAM. - I explained how identity trust scoring works today, at scale. This is not= hypothetical, just not used for phone calls at the moment. - If you're looking for perfection, there is no solution. The most likely o= utcome is that a vulnerable person can buy a service that says "only accept= calls from my address book, a registered bank, a real government agency an= d real health-care provider". No need for looking at names. - With the third-party identity provider model, whether the carrier is pink= or has any other color is largely immaterial. Henning -----Original Message----- From: Alex Bobotek [mailto:alex@bobotek.net]=20 Sent: Wednesday, August 28, 2013 1:55 AM To: Brian Rosen; Hadriel Kaplan Cc: Henning Schulzrinne; cnit@ietf.org; Dwight, Timothy M (Tim); Stephen Fa= rrell Subject: RE: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) The points that the originating service provider should be presenting and p= ossibly signing the display name I accept as generally positive. The orig= inating service provider is usually in the best position to provide this in= formation. And if some notion of originator reputation (e.g., 'score') is = also presented and signed by the originating service provider, great. =20 A display name service cannot provide an adequate basis for trust for sever= al reasons:=20 2. Further, even a perfect taxonomy of caller types (bank, person, ...)tha= t tells a called party that the caller is a person rather than a bank woul= d offer inadequate protection to vulnerable (e.g., permanently or temporari= ly disabled) individuals. Criminals are creative and will always find ways= to exploit the vulnerable with naming similarities. Nor could it, at leas= t without global adoption of identity authentication and registration requi= rements such as India's, be counted on to indicate telemarketing. I do not= see how a practical role-based naming taxonomy could be comprehensive enou= gh to prevent these exploits, but my ears are open if someone could point m= e to such an explanation. =20 3. We cannot assume that all originating service providers will be trustwo= rthy or even well intentioned. The opening of the service provider market = is increasing access to both reputable and disreputable parties. Display N= ames provided/signed only by an originating service provider should not be = trusted more than the service provider itself. =20 From br@brianrosen.net Wed Aug 28 06:41:23 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 1B63D11E81A4 for ; Wed, 28 Aug 2013 06:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.126 X-Spam-Level: X-Spam-Status: No, score=-103.126 tagged_above=-999 required=5 tests=[AWL=0.473, 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 L9IUuT-kSiAe for ; Wed, 28 Aug 2013 06:41:16 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7509A11E818C for ; Wed, 28 Aug 2013 06:41:14 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id l13so2931655qcy.39 for ; Wed, 28 Aug 2013 06:41:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Vzfo21QjVL4YaCWqCmgNPh1crxQwBWG6s2kOxU8oKw0=; b=g9RYS86E0hMUnUD6rigrGtAhYi1B7/Um9c4u6iQIWmxwqRg1ms2+7BAN5D8cB+FqLH DKTQqT73JljClMSuUCFwS/Xs2jISYdFANW/HH2oy9g1CWwMyUYYD/G/+ZQLnaRH2bAUY C5SqDjc22w+QaKd/kZs9e3RJjN7bQPpU+smN6Yl80187TI5HMIMbV3QDCy0sGPfoBugl 6BR/4Lz7h5k9MSL8ZJ2caJ3H5pZf8Dm7WwVJNeJCRkkMbi3siAO4pxw6iDflEqgzhJR6 ZnJNLcPSlzXc95dQc2BuSJ4R4w6qD7xaRfZn/OyzR8eLM+4twNsyEPG2yM+toY4scvtU P0Qg== X-Gm-Message-State: ALoCoQnQtlEqnSJD4zSBJZWafEXkXbv4zHZb58N56c1kZejp88HhDY2HswbcGG1BHLO7lVyqDvQO X-Received: by 10.49.12.108 with SMTP id x12mr30679323qeb.22.1377697273510; Wed, 28 Aug 2013 06:41:13 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id g3sm36727523qas.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 06:41:12 -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: <38C03DC1-C8CF-4C7A-9BE5-34A2169C2913@oracle.com> Date: Wed, 28 Aug 2013 09:41:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> <38C03DC1-C8CF-4C7A-9BE5-34A2169C2913@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: Henning Schulzrinne , "cnit@ietf.org" , Alex Bobotek , "Dwight, Timothy M \(Tim\)" , Stephen Farrell 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: Wed, 28 Aug 2013 13:41:23 -0000 I know I haven't been very articulate on this, but I'll try to be so in = this reply. The reason you want to sign the package with the credentials of the = number holder is that the validation is done at relatively long = intervals (say, months if we have a revocation mechanism), but we need = to stop a cut and paste attack, so we protect the package under the = number signature that has a timestamp and id/sequence number. The same package would be used in any call from that phone number. I don't want the validator to have to be in the path of every call. We = don't need that and it makes the mechanism much simpler. The entity asserting it has the right to use the number is the same = entity that asserts it has the right to the name, so it makes sense to = me to just put it in the stir signature. The entity asserting the name doesn't get a credential from the = validator, it gets the package. I think the package is the name, the canonical phone number, an id of = the validator, some id for the package (which could really just be a = small package version when combined with the name and number) and the = signature of the validator over the package. Brian On Aug 27, 2013, at 9:11 PM, Hadriel Kaplan = wrote: >=20 > Ignore the score thing for a minute - I think it's crazy to rely on = the sender's notion of a validity score (and that's not how spam score = systems work, for example) - but ignore that for now. >=20 > Let's just talk about this need to sign the stuff in the INVITE. I = think we must be talking past each other somehow. Either I'm missing = something, or you are, or both. :) >=20 > What is it you think you're gaining by having the validation service's = "package" signed by STIR? >=20 > Or maybe my disconnect is more basic than that - what exactly is in = the "package"? You don't have to describe every possible field, but = let's just say an absolutely plain/simplest package possible: what's in = it? >=20 > -hadriel >=20 >=20 > On Aug 27, 2013, at 6:49 PM, Brian Rosen wrote: >=20 >> We're proposing to change CNAM in a couple of ways: >> 1. We're proposing to move the name determination from the = termination to the origination >> 2. We're proposing to send a score=20 >>=20 >> We think the score can be used very effectively by the termination. = It can be used with a threshold, and the threshold can be set by the = termination service provider to match what service level it offers. = More interestingly, it can be used by the termination device to display = some useful data to the consumer that is not black or white. >>=20 >> We want the score to be as accurate as it can be. The databases have = dozens of fields, not all of which are populated for every record. The = more fields you provide, the more accurate the score is (and the higher = the score gets). If all you query with is name and phone number, the = confidence level is medium to low. If you have more data, like address = for example, the confidence is considerably higher. It's not that = address is better, it's that if you have a match of name AND number AND = address, you have a much smaller error. >>=20 >> The databases we have today use scores. >>=20 >> Just as an example, my company has such a database. It has dozens of = fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. >>=20 >> The exact same database is used for a call center caller match query. = You call the call center, the operator asks your name and address, gets = phone number from ANI and they query the database (same database) to get = a score of how likely the data in the query matches (name and phone = number and address match each other). The service you get depends on = that score. >>=20 >> We can provide a much better service if we have more information, and = the devices and services downstream can make use of score data to decide = how to present the call. >>=20 >> Brian >>=20 >> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>=20 >>>=20 >>> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>>=20 >>>> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>>=20 >>> Yes, I know they're queried on termination; and yes, I know they're = queried using the source telephone number. STIR will provide validity = for that source number, so that you can't pretend to be a source number = you aren't. That should make things better for calling names, if the = content of the calling name databases is accurate. You've been claiming = the content of the databases is fairly accurate. (and as far as I can = tell, they have been relatively accurate so far, for at least CNAM = databases though maybe not LIDB ones) >>>=20 >>> I know many folks don't like the CNAM model, but I believe they = don't like it due to the pricing model - not due to bad content, nor due = to having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>>=20 >>> I don't know what you mean by "that gets poor scores". As far as I = know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >>>=20 >>>=20 >>>> What we need is to do the dip at the origination side, where you = have more information to make the score larger, and securely carry it in = the SIP signaling. That is the problem to be solved - I have the name, = the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>>=20 >>> I think that jumps to a solution - presumably the problem is = "calling names aren't reliable"; the problem is not "we can't send = scores securely in SIP". >>>=20 >>> This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: >>> draft-wing-sipping-spam-score >>> draft-schwartz-sipping-spit-saml >>>=20 >>> -hadriel >>>=20 >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 From br@brianrosen.net Wed Aug 28 06:53:10 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 6BDE511E8190 for ; Wed, 28 Aug 2013 06:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.142 X-Spam-Level: X-Spam-Status: No, score=-103.142 tagged_above=-999 required=5 tests=[AWL=0.457, 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 rjeaDUFA7Uaq for ; Wed, 28 Aug 2013 06:52:54 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 28FDE21E804E for ; Wed, 28 Aug 2013 06:52:52 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id e1so1548314qcx.36 for ; Wed, 28 Aug 2013 06:52:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=8ncO2GPyCHDZqKgOnz3fNCph8bSfFSotfFYWIOfAfW4=; b=VJYWcOrn/u9gJu71bWfZrg4XVf3PD/5q3A/7l7oneWUwMtBGMYxb/284S8MCsxxe8v pOdqp54Sloan8Sniu/V95ziUkFZSG41pju7QlX13aD3BOLR2RMSo1mYRLHkovEbTwxhB ulEGjyyH88fnXQJHn6gW+zkzILe8fjvp4ipuxfWLMYVFn7Skvd6UpvFZ/okCiH9suqZq alMX941KN0Wwr0xnoAuOwmvN6JozL5VimCTyC/jssaJO2lAskDdGqYHQTodP274BbB3k VXQCI061+zT6a8y4Y69FOZzvJoqMnWo6iLlBD4gcWVlghDzhlTkrXClfWdQ4QYp6z3rD 00Zw== X-Gm-Message-State: ALoCoQkVe6jVPQSluPz1SYm8Hlux/o/n3vzsx988kOeMRqYVyWGhxDiYyzh5zPiKOJFZHKvucpwJ X-Received: by 10.49.18.195 with SMTP id y3mr30138910qed.39.1377697970659; Wed, 28 Aug 2013 06:52:50 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id x2sm36797133qat.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 06:52:49 -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: <521D53D9.2080008@alum.mit.edu> Date: Wed, 28 Aug 2013 09:52:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15603CA4-534A-4CCB-9EC4-9EFFD17B8B47@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> <521D53D9.2080008@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org 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: Wed, 28 Aug 2013 13:53:10 -0000 On Aug 27, 2013, at 9:35 PM, Paul Kyzivat wrote: > Brian, >=20 > Like Hadriel, I'm not getting your point about the score, and what = having a bunch of factors says about the score. >=20 > I can see that if I'm trying to enroll with some naming service that = they would want to get a bunch of facts from me to verify I am who I say = I am. And if I have less facts then they are less certain who I am. That = could enter into a score they give when queried. Yes >=20 > But I don't see what that has to do with this problem. >=20 > One possibility is that the originator of the call always uses one = name per phone number, in which case getting the name by looking up the = phone number is fine. In that case, the score depends on what facts were = given when the name was assigned to the number in the db. The lookup can = be done by the recipient without loss of function. You missed the part where we proposed that the name comes in the = signaling from the sender. There is no lookup by phone number. We could do that, but the proposal is to change the CNAM mechanism to = carry the name in the signaling. The score would come in the signaling. The recipient gets a name, and = it gets the score, and it gets a signature of one of a small number of = validators that asserts the score. It then can evaluate, based on it's = trust in the validator, and the score, what to display to the user. To be clear, it is possible to do something like send the id of the = validator in the signaling, and then query the validator at the = recipient with the phone number to get the name and the score. That = would be equivalent to what I propose, but it isn't what I'm proposing. >=20 > Another possibility is that the originator wants the option of using = multiple names with the same number. (One for any given call.) For that = to work, I guess all the possible names for a number must be enrolled. = And presumably each of them get a score. In this case the phone number = isn't sufficient to lookup the name. But the caller could include the = name in the signaling, and the recipient could provide both the name and = number for lookup. Then I would succeed, with a score, if that is one of = the enrolled names for the number. Else it would fail. Not proposing multiple names per number >=20 > Another possibility is that signing of names is entirely independent = of the signing of numbers, with possibly different entities doing it. In = that case I agree that the recipient looking up the number won't give = the same result. This seems something like a SAML system. The proposal is that the name is signed by one of a small number of name = validators, and those are independent of the number delegation based = credentials issued to sign the number. I just replied to Hadriel with = the explanation of why I propose we mix them (because the name = validation is done infrequently, and is used for multiple calls, so to = prevent cut/paste, we cover it with the per-call number signature). >=20 > Thanks, > Paul >=20 > On 8/27/13 6:49 PM, Brian Rosen wrote: >> We're proposing to change CNAM in a couple of ways: >> 1. We're proposing to move the name determination from the = termination to the origination >> 2. We're proposing to send a score >>=20 >> We think the score can be used very effectively by the termination. = It can be used with a threshold, and the threshold can be set by the = termination service provider to match what service level it offers. = More interestingly, it can be used by the termination device to display = some useful data to the consumer that is not black or white. >>=20 >> We want the score to be as accurate as it can be. The databases have = dozens of fields, not all of which are populated for every record. The = more fields you provide, the more accurate the score is (and the higher = the score gets). If all you query with is name and phone number, the = confidence level is medium to low. If you have more data, like address = for example, the confidence is considerably higher. It's not that = address is better, it's that if you have a match of name AND number AND = address, you have a much smaller error. >>=20 >> The databases we have today use scores. >>=20 >> Just as an example, my company has such a database. It has dozens of = fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. >>=20 >> The exact same database is used for a call center caller match query. = You call the call center, the operator asks your name and address, gets = phone number from ANI and they query the database (same database) to get = a score of how likely the data in the query matches (name and phone = number and address match each other). The service you get depends on = that score. >>=20 >> We can provide a much better service if we have more information, and = the devices and services downstream can make use of score data to decide = how to present the call. >>=20 >> Brian >>=20 >> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>=20 >>>=20 >>> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>>=20 >>>> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>>=20 >>> Yes, I know they're queried on termination; and yes, I know they're = queried using the source telephone number. STIR will provide validity = for that source number, so that you can't pretend to be a source number = you aren't. That should make things better for calling names, if the = content of the calling name databases is accurate. You've been claiming = the content of the databases is fairly accurate. (and as far as I can = tell, they have been relatively accurate so far, for at least CNAM = databases though maybe not LIDB ones) >>>=20 >>> I know many folks don't like the CNAM model, but I believe they = don't like it due to the pricing model - not due to bad content, nor due = to having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>>=20 >>> I don't know what you mean by "that gets poor scores". As far as I = know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >>>=20 >>>=20 >>>> What we need is to do the dip at the origination side, where you = have more information to make the score larger, and securely carry it in = the SIP signaling. That is the problem to be solved - I have the name, = the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>>=20 >>> I think that jumps to a solution - presumably the problem is = "calling names aren't reliable"; the problem is not "we can't send = scores securely in SIP". >>>=20 >>> This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: >>> draft-wing-sipping-spam-score >>> draft-schwartz-sipping-spit-saml >>>=20 >>> -hadriel >>>=20 >>=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 Wed Aug 28 07:30: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 1A3DD21F9B18 for ; Wed, 28 Aug 2013 07:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[AWL=0.119, 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 1pBDChdvn5fb for ; Wed, 28 Aug 2013 07:30:21 -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 19DE611E811F for ; Wed, 28 Aug 2013 07:30:19 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id JB9h1m0020ldTLk55EWKU4; Wed, 28 Aug 2013 14:30:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id JEWJ1m01b3ZTu2S01EWJ4m; Wed, 28 Aug 2013 14:30:19 +0000 Message-ID: <521E097A.6010508@alum.mit.edu> Date: Wed, 28 Aug 2013 10:30:18 -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: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> In-Reply-To: <15603CA4-534A-4CCB-9EC4-9EFFD17B8B47@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=1377700219; bh=BN27UqXxKqGkm7wFw75XzbqxcBWXwjb1lZIKt2Lq6/E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DCwdHhH8v4m0DfO07WBJJR4dYtd76zVshOo0llqTMjeDiRr7Sxa5rg932JkoOuE/6 HW+iPf3W45OV1aD6ZDlzIjhAy+pMomEfvM58SBQCDnp0bMsjevbSiuCZex989G3V1E TRFXUWAmN3qJU5mcySPJgX2Bb3o6p0QZw6HscSE7ZOk2BiaZNMcm1KEaxE6Z8uUPml LvOhigyAyDH1DY4pD1SYeCZTtMXdhH0RkuNAigSBPTAsDzhNh1g6qyopXJAi//GhJH LZ+DYHXqaG/ZUaf0ollTL3gSWrb1BliPeu/X2t/nGz1HS6Vyfipc9YbaMFz3RpDx9Q MWj+a7bpTbPng== Cc: cnit@ietf.org 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: Wed, 28 Aug 2013 14:30:26 -0000 Brian, OK, clearly I don't understand what you are proposing. Can you explain it better? On one hand I think you are assuming a service that can be queried with a bunch of factors, and returns a confidence score that that combination of factors is valid. E.g., I might present a name and number and get a score. Or I might present a name, number, and some other secrets known to the caller, and get a score. Assuming there is some value in using that extra information, and assuming the extra information is something that the caller doesn't want to share with the callee, then I see why the caller would need to do the query rather than the callee. How is that to be communicated to the callee? You seen to say that the service will return some sort of signed object that the recipient can understand. Presumably that object must include the name, number, and score in some crypto-protected form. I guess this means that the request must be of the form: please score (number,name,x,y,z) and return the score in cert showing only (number,name,score). This is presumably possible, though it seems a bit weird. My problem with the above is that you suggest that giving more information will get a higher score. I don't understand why. If the name/number combination is valid, then its valid. How much better can it get than that? Any increased score due to more inputs being correct only pertains to the extra attributes, not the name/number. Thanks, Paul On 8/28/13 9:52 AM, Brian Rosen wrote: > > On Aug 27, 2013, at 9:35 PM, Paul Kyzivat wrote: > >> Brian, >> >> Like Hadriel, I'm not getting your point about the score, and what having a bunch of factors says about the score. >> >> I can see that if I'm trying to enroll with some naming service that they would want to get a bunch of facts from me to verify I am who I say I am. And if I have less facts then they are less certain who I am. That could enter into a score they give when queried. > Yes >> >> But I don't see what that has to do with this problem. >> >> One possibility is that the originator of the call always uses one name per phone number, in which case getting the name by looking up the phone number is fine. In that case, the score depends on what facts were given when the name was assigned to the number in the db. The lookup can be done by the recipient without loss of function. > You missed the part where we proposed that the name comes in the signaling from the sender. > > There is no lookup by phone number. > > We could do that, but the proposal is to change the CNAM mechanism to carry the name in the signaling. > > The score would come in the signaling. The recipient gets a name, and it gets the score, and it gets a signature of one of a small number of validators that asserts the score. It then can evaluate, based on it's trust in the validator, and the score, what to display to the user. > > To be clear, it is possible to do something like send the id of the validator in the signaling, and then query the validator at the recipient with the phone number to get the name and the score. That would be equivalent to what I propose, but it isn't what I'm proposing. > >> >> Another possibility is that the originator wants the option of using multiple names with the same number. (One for any given call.) For that to work, I guess all the possible names for a number must be enrolled. And presumably each of them get a score. In this case the phone number isn't sufficient to lookup the name. But the caller could include the name in the signaling, and the recipient could provide both the name and number for lookup. Then I would succeed, with a score, if that is one of the enrolled names for the number. Else it would fail. > Not proposing multiple names per number > >> >> Another possibility is that signing of names is entirely independent of the signing of numbers, with possibly different entities doing it. In that case I agree that the recipient looking up the number won't give the same result. This seems something like a SAML system. > The proposal is that the name is signed by one of a small number of name validators, and those are independent of the number delegation based credentials issued to sign the number. I just replied to Hadriel with the explanation of why I propose we mix them (because the name validation is done infrequently, and is used for multiple calls, so to prevent cut/paste, we cover it with the per-call number signature). > >> >> Thanks, >> Paul >> >> On 8/27/13 6:49 PM, Brian Rosen wrote: >>> We're proposing to change CNAM in a couple of ways: >>> 1. We're proposing to move the name determination from the termination to the origination >>> 2. We're proposing to send a score >>> >>> We think the score can be used very effectively by the termination. It can be used with a threshold, and the threshold can be set by the termination service provider to match what service level it offers. More interestingly, it can be used by the termination device to display some useful data to the consumer that is not black or white. >>> >>> We want the score to be as accurate as it can be. The databases have dozens of fields, not all of which are populated for every record. The more fields you provide, the more accurate the score is (and the higher the score gets). If all you query with is name and phone number, the confidence level is medium to low. If you have more data, like address for example, the confidence is considerably higher. It's not that address is better, it's that if you have a match of name AND number AND address, you have a much smaller error. >>> >>> The databases we have today use scores. >>> >>> Just as an example, my company has such a database. It has dozens of fields. One of the products that is driven by the database is a CNAM service. When the termination side dips the database, it does so only with the telephone number. The scores are fairly low, but there is a threshold (I don't actually know the details). You get a name, or no entry found out of that dip. The database scores the data and applies a threshold to it. >>> >>> The exact same database is used for a call center caller match query. You call the call center, the operator asks your name and address, gets phone number from ANI and they query the database (same database) to get a score of how likely the data in the query matches (name and phone number and address match each other). The service you get depends on that score. >>> >>> We can provide a much better service if we have more information, and the devices and services downstream can make use of score data to decide how to present the call. >>> >>> Brian >>> >>> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan wrote: >>> >>>> >>>> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>>> >>>>> As I keep saying, over and over, what they are used for today is termination dips, where all you have to query with is the telephone number, and that gets poor scores. >>>> >>>> Yes, I know they're queried on termination; and yes, I know they're queried using the source telephone number. STIR will provide validity for that source number, so that you can't pretend to be a source number you aren't. That should make things better for calling names, if the content of the calling name databases is accurate. You've been claiming the content of the databases is fairly accurate. (and as far as I can tell, they have been relatively accurate so far, for at least CNAM databases though maybe not LIDB ones) >>>> >>>> I know many folks don't like the CNAM model, but I believe they don't like it due to the pricing model - not due to bad content, nor due to having to physically query it. They don't like the fact that the receiver of calls has to pay extra for getting data the far-end wanted to be delivered to begin with. >>>> >>>> I don't know what you mean by "that gets poor scores". As far as I know, there is no such thing as a "score" in the existing PSTN calling name market. There are name/number/phone-service "types" or category, but not scores of name accuracy afaik. Are there such things? Why would anyone claim their score is anything but perfect? >>>> >>>> >>>>> What we need is to do the dip at the origination side, where you have more information to make the score larger, and securely carry it in the SIP signaling. That is the problem to be solved - I have the name, the score, and the identity of the validator. I have to get that information across reliably, and reliably includes preventing messing with it at the origination side (so the sender can't lie about the score). >>>> >>>> I think that jumps to a solution - presumably the problem is "calling names aren't reliable"; the problem is not "we can't send scores securely in SIP". >>>> >>>> This whole topic is reminiscent of the debates the SIPPING WG had years ago on: >>>> draft-wing-sipping-spam-score >>>> draft-schwartz-sipping-spit-saml >>>> >>>> -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 hadriel.kaplan@oracle.com Wed Aug 28 08:30:40 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 BEFCC11E819A for ; Wed, 28 Aug 2013 08:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 t06U1cY6Hptx for ; Wed, 28 Aug 2013 08:30:35 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 33F9A11E8191 for ; Wed, 28 Aug 2013 08:30:35 -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 r7SFURYE002645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Aug 2013 15:30:27 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7SFUM0o020577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 15:30:23 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7SFULeC009412; Wed, 28 Aug 2013 15:30:22 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Aug 2013 08:30:21 -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, 28 Aug 2013 11:30:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <87ED4D02-7400-437C-BCD9-E44EBEC2ADCB@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.net> <78218B3E-8293-4F7F-85C2-EA6547BD312E@oracle.com> <9767A883-6957-4AEA-9F3C-77B270EE13CD@brianrosen.net> <38C03DC1-C8CF-4C7A-9BE5-34A2169C2913@oracle.com> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "cnit@ietf.org" , Alex Bobotek , "Dwight, Timothy M \(Tim\)" , Stephen Farrell , Henning Schulzrinne 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: Wed, 28 Aug 2013 15:30:40 -0000 OK good, the "package contains the phone number. I was worried you were = saying it didn't contain the number. So the minimal "package" contains = the name, E.164 number, and the signature of the validation service. To avoid confusion, let's call the validation service's signature in the = package the "varsig", and the SIP INVITE's STIR-based signature the = sipsig (this would be the one in the STIR SIP header). So let's say you, Brian Rosen, had your name verified by TrueName. The = package given to you by TrueName contained: {name=3D"Brian Rosen", = number=3D"+17245551234", varsig=3D}. Signing that package with the sipsig for 17245551234 isn't what prevents = cut-and-paste. It would prevent someone from replacing the package = while still pretending to be 17245551234. But they couldn't do that = *anyway*, or else the concept of STIR itself is broken, since the whole = premise of STIR is to prevent someone else from claiming to be your = number. So let's talk about a different form of cut-and-paste: if you call me, I = can copy just the "package" from your INVITE and put it in an INVITE of = my own, and sipsig sign it with my own source number, and thus pretend = to be Brian Rosen. But what makes the package useful is the fact that = it contains the phone number, and that we have a way to verify the phone = number sender of the INVITE; and that's what prevents me from being able = to re-use your package in my INVITE, not the the fact that it was sipsig = signed by your private key. In other words, the actual calling name binding and verification check = required by receivers of the call is to verify that the phone number in = the package matches the phone number of the INVITE sender; and STIR's = sipsig verifies the phone number of the INVITE sender. Using sipsig to = sign the package isn't necessary. -hadriel On Aug 28, 2013, at 9:41 AM, Brian Rosen wrote: > The reason you want to sign the package with the credentials of the = number holder is that the validation is done at relatively long = intervals (say, months if we have a revocation mechanism), but we need = to stop a cut and paste attack, so we protect the package under the = number signature that has a timestamp and id/sequence number. >=20 > The same package would be used in any call from that phone number. >=20 > I don't want the validator to have to be in the path of every call. = We don't need that and it makes the mechanism much simpler. >=20 > The entity asserting it has the right to use the number is the same = entity that asserts it has the right to the name, so it makes sense to = me to just put it in the stir signature. >=20 > The entity asserting the name doesn't get a credential from the = validator, it gets the package. >=20 > I think the package is the name, the canonical phone number, an id of = the validator, some id for the package (which could really just be a = small package version when combined with the name and number) and the = signature of the validator over the package. >=20 > Brian >=20 > On Aug 27, 2013, at 9:11 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> Ignore the score thing for a minute - I think it's crazy to rely on = the sender's notion of a validity score (and that's not how spam score = systems work, for example) - but ignore that for now. >>=20 >> Let's just talk about this need to sign the stuff in the INVITE. I = think we must be talking past each other somehow. Either I'm missing = something, or you are, or both. :) >>=20 >> What is it you think you're gaining by having the validation = service's "package" signed by STIR? >>=20 >> Or maybe my disconnect is more basic than that - what exactly is in = the "package"? You don't have to describe every possible field, but = let's just say an absolutely plain/simplest package possible: what's in = it? >>=20 >> -hadriel >>=20 >>=20 >> On Aug 27, 2013, at 6:49 PM, Brian Rosen wrote: >>=20 >>> We're proposing to change CNAM in a couple of ways: >>> 1. We're proposing to move the name determination from the = termination to the origination >>> 2. We're proposing to send a score=20 >>>=20 >>> We think the score can be used very effectively by the termination. = It can be used with a threshold, and the threshold can be set by the = termination service provider to match what service level it offers. = More interestingly, it can be used by the termination device to display = some useful data to the consumer that is not black or white. >>>=20 >>> We want the score to be as accurate as it can be. The databases = have dozens of fields, not all of which are populated for every record. = The more fields you provide, the more accurate the score is (and the = higher the score gets). If all you query with is name and phone number, = the confidence level is medium to low. If you have more data, like = address for example, the confidence is considerably higher. It's not = that address is better, it's that if you have a match of name AND number = AND address, you have a much smaller error. >>>=20 >>> The databases we have today use scores. >>>=20 >>> Just as an example, my company has such a database. It has dozens = of fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. >>>=20 >>> The exact same database is used for a call center caller match = query. You call the call center, the operator asks your name and = address, gets phone number from ANI and they query the database (same = database) to get a score of how likely the data in the query matches = (name and phone number and address match each other). The service you = get depends on that score. >>>=20 >>> We can provide a much better service if we have more information, = and the devices and services downstream can make use of score data to = decide how to present the call. >>>=20 >>> Brian >>>=20 >>> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>>=20 >>>>=20 >>>> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>>>=20 >>>>> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>>>=20 >>>> Yes, I know they're queried on termination; and yes, I know they're = queried using the source telephone number. STIR will provide validity = for that source number, so that you can't pretend to be a source number = you aren't. That should make things better for calling names, if the = content of the calling name databases is accurate. You've been claiming = the content of the databases is fairly accurate. (and as far as I can = tell, they have been relatively accurate so far, for at least CNAM = databases though maybe not LIDB ones) >>>>=20 >>>> I know many folks don't like the CNAM model, but I believe they = don't like it due to the pricing model - not due to bad content, nor due = to having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>>>=20 >>>> I don't know what you mean by "that gets poor scores". As far as I = know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >>>>=20 >>>>=20 >>>>> What we need is to do the dip at the origination side, where you = have more information to make the score larger, and securely carry it in = the SIP signaling. That is the problem to be solved - I have the name, = the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>>>=20 >>>> I think that jumps to a solution - presumably the problem is = "calling names aren't reliable"; the problem is not "we can't send = scores securely in SIP". >>>>=20 >>>> This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: >>>> draft-wing-sipping-spam-score >>>> draft-schwartz-sipping-spit-saml >>>>=20 >>>> -hadriel >>>>=20 >>>=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 br@brianrosen.net Wed Aug 28 08:31: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 BC80111E819A for ; Wed, 28 Aug 2013 08:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.157 X-Spam-Level: X-Spam-Status: No, score=-103.157 tagged_above=-999 required=5 tests=[AWL=0.442, 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 WcmIZbTP5EQe for ; Wed, 28 Aug 2013 08:31:14 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id C381F11E81A4 for ; Wed, 28 Aug 2013 08:31:13 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd6so6878420obb.33 for ; Wed, 28 Aug 2013 08:31:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=M1JjkOgPLuUpYDT+wOaOA0mUL2K2aBekXcUwEGlFkC8=; b=Qu9CANXJ06BcFTg9TL2hBc3gXfpXWaHfbNsOwMhk0O9MhBUg2SNvHfi9qgiUcIfVGe 8OjyHp+br/elkwxbrHvynEYAImQztn5j7RZmQWDchQlckQ1c4XsU2dwml/pmYC8rEXYf ohpBAT7310AIICFdJaufpVha4OoduYNCUi/YRURoJ9H0faBWX2YQCqxaGkwRocJYNZt6 /1vjWc7KLr2yji8OUwqj6oldyQ94L/2MOAyUk1C5//j8MEfE/9ltMDOeEcCV/LZhBIy9 tULzMZDXd7TUTB5wxF4I5qM1d7Ti4iyfS08VURrS4j0dDds2zroB1OW/c5p5BmWJnHu2 Z3Cg== X-Gm-Message-State: ALoCoQkcxpTlLfLY8TK9mx7sG1hl2EnnB+Q0G1LliV8CJj3pWMvN2FRubhhmyZGHKzWwHekDq+rn X-Received: by 10.182.113.195 with SMTP id ja3mr6958111obb.46.1377703873140; Wed, 28 Aug 2013 08:31:13 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id rr6sm27150580oeb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 08:31:11 -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: <521E097A.6010508@alum.mit.edu> Date: Wed, 28 Aug 2013 11:31:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org 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: Wed, 28 Aug 2013 15:31:19 -0000 I'll try to step through this carefully. 1. Assume stir credentials assigned, so sending SP has credential for = +12125551212 2. At service initiation sending SP gets name and other info from its = subscriber. It sends info to its chosen validation service (with = number), and receives a score and a signature in response. = Re-validation is done periodically, say months. 3. At call time, sending SP puts name in display name part of = From/P-A-I, and includes score and signature in stir header (and = probably a digest of the name, so the name can be munged and have the = stir header check work) 4. Receiver SP verifies signature in stir header 5. Receiver SP verifies signature of validator, which has a well known = credential 6. Based on score, receiver SP decides how to populate display name for = recipient device, or it may pass the score to the receiver device for = display. Brian On Aug 28, 2013, at 10:30 AM, Paul Kyzivat = wrote: > Brian, >=20 > OK, clearly I don't understand what you are proposing. Can you explain = it better? >=20 > On one hand I think you are assuming a service that can be queried = with a bunch of factors, and returns a confidence score that that = combination of factors is valid. E.g., I might present a name and number = and get a score. Or I might present a name, number, and some other = secrets known to the caller, and get a score. >=20 > Assuming there is some value in using that extra information, and = assuming the extra information is something that the caller doesn't want = to share with the callee, then I see why the caller would need to do the = query rather than the callee. >=20 > How is that to be communicated to the callee? You seen to say that the = service will return some sort of signed object that the recipient can = understand. Presumably that object must include the name, number, and = score in some crypto-protected form. I guess this means that the request = must be of the form: please score (number,name,x,y,z) and return the = score in cert showing only (number,name,score). This is presumably = possible, though it seems a bit weird. >=20 > My problem with the above is that you suggest that giving more = information will get a higher score. I don't understand why. If the = name/number combination is valid, then its valid. How much better can it = get than that? Any increased score due to more inputs being correct only = pertains to the extra attributes, not the name/number. >=20 > Thanks, > Paul >=20 > On 8/28/13 9:52 AM, Brian Rosen wrote: >>=20 >> On Aug 27, 2013, at 9:35 PM, Paul Kyzivat = wrote: >>=20 >>> Brian, >>>=20 >>> Like Hadriel, I'm not getting your point about the score, and what = having a bunch of factors says about the score. >>>=20 >>> I can see that if I'm trying to enroll with some naming service that = they would want to get a bunch of facts from me to verify I am who I say = I am. And if I have less facts then they are less certain who I am. That = could enter into a score they give when queried. >> Yes >>>=20 >>> But I don't see what that has to do with this problem. >>>=20 >>> One possibility is that the originator of the call always uses one = name per phone number, in which case getting the name by looking up the = phone number is fine. In that case, the score depends on what facts were = given when the name was assigned to the number in the db. The lookup can = be done by the recipient without loss of function. >> You missed the part where we proposed that the name comes in the = signaling from the sender. >>=20 >> There is no lookup by phone number. >>=20 >> We could do that, but the proposal is to change the CNAM mechanism to = carry the name in the signaling. >>=20 >> The score would come in the signaling. The recipient gets a name, = and it gets the score, and it gets a signature of one of a small number = of validators that asserts the score. It then can evaluate, based on = it's trust in the validator, and the score, what to display to the user. >>=20 >> To be clear, it is possible to do something like send the id of the = validator in the signaling, and then query the validator at the = recipient with the phone number to get the name and the score. That = would be equivalent to what I propose, but it isn't what I'm proposing. >>=20 >>>=20 >>> Another possibility is that the originator wants the option of using = multiple names with the same number. (One for any given call.) For that = to work, I guess all the possible names for a number must be enrolled. = And presumably each of them get a score. In this case the phone number = isn't sufficient to lookup the name. But the caller could include the = name in the signaling, and the recipient could provide both the name and = number for lookup. Then I would succeed, with a score, if that is one of = the enrolled names for the number. Else it would fail. >> Not proposing multiple names per number >>=20 >>>=20 >>> Another possibility is that signing of names is entirely independent = of the signing of numbers, with possibly different entities doing it. In = that case I agree that the recipient looking up the number won't give = the same result. This seems something like a SAML system. >> The proposal is that the name is signed by one of a small number of = name validators, and those are independent of the number delegation = based credentials issued to sign the number. I just replied to Hadriel = with the explanation of why I propose we mix them (because the name = validation is done infrequently, and is used for multiple calls, so to = prevent cut/paste, we cover it with the per-call number signature). >>=20 >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 8/27/13 6:49 PM, Brian Rosen wrote: >>>> We're proposing to change CNAM in a couple of ways: >>>> 1. We're proposing to move the name determination from the = termination to the origination >>>> 2. We're proposing to send a score >>>>=20 >>>> We think the score can be used very effectively by the termination. = It can be used with a threshold, and the threshold can be set by the = termination service provider to match what service level it offers. = More interestingly, it can be used by the termination device to display = some useful data to the consumer that is not black or white. >>>>=20 >>>> We want the score to be as accurate as it can be. The databases = have dozens of fields, not all of which are populated for every record. = The more fields you provide, the more accurate the score is (and the = higher the score gets). If all you query with is name and phone number, = the confidence level is medium to low. If you have more data, like = address for example, the confidence is considerably higher. It's not = that address is better, it's that if you have a match of name AND number = AND address, you have a much smaller error. >>>>=20 >>>> The databases we have today use scores. >>>>=20 >>>> Just as an example, my company has such a database. It has dozens = of fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. >>>>=20 >>>> The exact same database is used for a call center caller match = query. You call the call center, the operator asks your name and = address, gets phone number from ANI and they query the database (same = database) to get a score of how likely the data in the query matches = (name and phone number and address match each other). The service you = get depends on that score. >>>>=20 >>>> We can provide a much better service if we have more information, = and the devices and services downstream can make use of score data to = decide how to present the call. >>>>=20 >>>> Brian >>>>=20 >>>> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>>>=20 >>>>>=20 >>>>> On Aug 27, 2013, at 4:41 PM, Brian Rosen = wrote: >>>>>=20 >>>>>> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>>>>=20 >>>>> Yes, I know they're queried on termination; and yes, I know = they're queried using the source telephone number. STIR will provide = validity for that source number, so that you can't pretend to be a = source number you aren't. That should make things better for calling = names, if the content of the calling name databases is accurate. You've = been claiming the content of the databases is fairly accurate. (and as = far as I can tell, they have been relatively accurate so far, for at = least CNAM databases though maybe not LIDB ones) >>>>>=20 >>>>> I know many folks don't like the CNAM model, but I believe they = don't like it due to the pricing model - not due to bad content, nor due = to having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>>>>=20 >>>>> I don't know what you mean by "that gets poor scores". As far as = I know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >>>>>=20 >>>>>=20 >>>>>> What we need is to do the dip at the origination side, where you = have more information to make the score larger, and securely carry it in = the SIP signaling. That is the problem to be solved - I have the name, = the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>>>>=20 >>>>> I think that jumps to a solution - presumably the problem is = "calling names aren't reliable"; the problem is not "we can't send = scores securely in SIP". >>>>>=20 >>>>> This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: >>>>> draft-wing-sipping-spam-score >>>>> draft-schwartz-sipping-spit-saml >>>>>=20 >>>>> -hadriel >>>>>=20 >>>>=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 pkyzivat@alum.mit.edu Wed Aug 28 10:09:31 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 2A34621F9EEC for ; Wed, 28 Aug 2013 10:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=0.118, 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 qwnPMLDmc81a for ; Wed, 28 Aug 2013 10:09:26 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 471A521F9EDF for ; Wed, 28 Aug 2013 10:09:26 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id JCfp1m0071c6gX851H9RS0; Wed, 28 Aug 2013 17:09:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id JH9R1m00c3ZTu2S3jH9RKs; Wed, 28 Aug 2013 17:09:25 +0000 Message-ID: <521E2EC4.9070805@alum.mit.edu> Date: Wed, 28 Aug 2013 13:09:24 -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: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> In-Reply-To: <02E32E0F-C731-47D7-AC48-4D0E015D9437@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=1377709765; bh=HikbHaUmUlVTqBKMBNe6/eU0OhOJJIFtWVsDpdl8LSY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M0wsiS0aCCGe/Yq4NvmMSKwyxl9zNRUwB3LNwnOQpWnMCbeI8HKqR1XbNXJ+S7m8a ASL5XGX+wIagI1Lb04+y09qppVrqmLn6PTDGYkKA/41NE7yXu/rLZjAPYsmwzdGMuM a8CsvbxpDsxuaUvBxqJgXUTZ0xxOArj3DBkSA6wCboP4ASvZTHKA/KBnr/CLXZyL8X shhdSQVHp49FdjpNffP1gShvaFkjDLNb/tuOOD55oVJYOaGRUUPObBQHsfQHhDKqZ/ 17PvEY6hejS1H4KO0D5DPqJ2m+8qfc6uwTVslDu7ybpev4sgiS2VpumgsRQbgA06uP PBWQq/HFwSuhw== Cc: cnit@ietf.org 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: Wed, 28 Aug 2013 17:09:31 -0000 On 8/28/13 11:31 AM, Brian Rosen wrote: > I'll try to step through this carefully. Thanks. > 1. Assume stir credentials assigned, so sending SP has credential for +12125551212 And this is independent of the (name) validation service, right? > 2. At service initiation sending SP gets name and other info from its subscriber. So a key point is that the validation service is not in the call path. It doesn't have the same real-time constraints. > It sends info to its chosen validation service (with number), and receives a score and a signature in response. Re-validation is done periodically, say months. What is signed? Number+name+score? ISTM that such a signature attests to the combination signed, and in particular that the score pertains to the other signed information. I don't see how it would make sense for information that isn't signed to affect the score. Or do you intend that the other info sent to the validator is proof that the requester is the holder of the credential for the number? (In lieu of including that in calls.) > 3. At call time, sending SP puts name in display name part of From/P-A-I, and includes score and signature in stir header (and probably a digest of the name, so the name can be munged and have the stir header check work) > 4. Receiver SP verifies signature in stir header > 5. Receiver SP verifies signature of validator, which has a well known credential > 6. Based on score, receiver SP decides how to populate display name for recipient device, or it may pass the score to the receiver device for display. ISTM that you can achieve the same effect by putting a signed number and an unsigned name in the call. The recipient then verifies the signature on the number. Then it takes the name and number and requests a score from a validator. This requires the validator in the call path. But the receiving SP can cache these and build its own DB. Thanks, Paul > Brian > On Aug 28, 2013, at 10:30 AM, Paul Kyzivat wrote: > >> Brian, >> >> OK, clearly I don't understand what you are proposing. Can you explain it better? >> >> On one hand I think you are assuming a service that can be queried with a bunch of factors, and returns a confidence score that that combination of factors is valid. E.g., I might present a name and number and get a score. Or I might present a name, number, and some other secrets known to the caller, and get a score. >> >> Assuming there is some value in using that extra information, and assuming the extra information is something that the caller doesn't want to share with the callee, then I see why the caller would need to do the query rather than the callee. >> >> How is that to be communicated to the callee? You seen to say that the service will return some sort of signed object that the recipient can understand. Presumably that object must include the name, number, and score in some crypto-protected form. I guess this means that the request must be of the form: please score (number,name,x,y,z) and return the score in cert showing only (number,name,score). This is presumably possible, though it seems a bit weird. >> >> My problem with the above is that you suggest that giving more information will get a higher score. I don't understand why. If the name/number combination is valid, then its valid. How much better can it get than that? Any increased score due to more inputs being correct only pertains to the extra attributes, not the name/number. >> >> Thanks, >> Paul >> >> On 8/28/13 9:52 AM, Brian Rosen wrote: >>> >>> On Aug 27, 2013, at 9:35 PM, Paul Kyzivat wrote: >>> >>>> Brian, >>>> >>>> Like Hadriel, I'm not getting your point about the score, and what having a bunch of factors says about the score. >>>> >>>> I can see that if I'm trying to enroll with some naming service that they would want to get a bunch of facts from me to verify I am who I say I am. And if I have less facts then they are less certain who I am. That could enter into a score they give when queried. >>> Yes >>>> >>>> But I don't see what that has to do with this problem. >>>> >>>> One possibility is that the originator of the call always uses one name per phone number, in which case getting the name by looking up the phone number is fine. In that case, the score depends on what facts were given when the name was assigned to the number in the db. The lookup can be done by the recipient without loss of function. >>> You missed the part where we proposed that the name comes in the signaling from the sender. >>> >>> There is no lookup by phone number. >>> >>> We could do that, but the proposal is to change the CNAM mechanism to carry the name in the signaling. >>> >>> The score would come in the signaling. The recipient gets a name, and it gets the score, and it gets a signature of one of a small number of validators that asserts the score. It then can evaluate, based on it's trust in the validator, and the score, what to display to the user. >>> >>> To be clear, it is possible to do something like send the id of the validator in the signaling, and then query the validator at the recipient with the phone number to get the name and the score. That would be equivalent to what I propose, but it isn't what I'm proposing. >>> >>>> >>>> Another possibility is that the originator wants the option of using multiple names with the same number. (One for any given call.) For that to work, I guess all the possible names for a number must be enrolled. And presumably each of them get a score. In this case the phone number isn't sufficient to lookup the name. But the caller could include the name in the signaling, and the recipient could provide both the name and number for lookup. Then I would succeed, with a score, if that is one of the enrolled names for the number. Else it would fail. >>> Not proposing multiple names per number >>> >>>> >>>> Another possibility is that signing of names is entirely independent of the signing of numbers, with possibly different entities doing it. In that case I agree that the recipient looking up the number won't give the same result. This seems something like a SAML system. >>> The proposal is that the name is signed by one of a small number of name validators, and those are independent of the number delegation based credentials issued to sign the number. I just replied to Hadriel with the explanation of why I propose we mix them (because the name validation is done infrequently, and is used for multiple calls, so to prevent cut/paste, we cover it with the per-call number signature). >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 8/27/13 6:49 PM, Brian Rosen wrote: >>>>> We're proposing to change CNAM in a couple of ways: >>>>> 1. We're proposing to move the name determination from the termination to the origination >>>>> 2. We're proposing to send a score >>>>> >>>>> We think the score can be used very effectively by the termination. It can be used with a threshold, and the threshold can be set by the termination service provider to match what service level it offers. More interestingly, it can be used by the termination device to display some useful data to the consumer that is not black or white. >>>>> >>>>> We want the score to be as accurate as it can be. The databases have dozens of fields, not all of which are populated for every record. The more fields you provide, the more accurate the score is (and the higher the score gets). If all you query with is name and phone number, the confidence level is medium to low. If you have more data, like address for example, the confidence is considerably higher. It's not that address is better, it's that if you have a match of name AND number AND address, you have a much smaller error. >>>>> >>>>> The databases we have today use scores. >>>>> >>>>> Just as an example, my company has such a database. It has dozens of fields. One of the products that is driven by the database is a CNAM service. When the termination side dips the database, it does so only with the telephone number. The scores are fairly low, but there is a threshold (I don't actually know the details). You get a name, or no entry found out of that dip. The database scores the data and applies a threshold to it. >>>>> >>>>> The exact same database is used for a call center caller match query. You call the call center, the operator asks your name and address, gets phone number from ANI and they query the database (same database) to get a score of how likely the data in the query matches (name and phone number and address match each other). The service you get depends on that score. >>>>> >>>>> We can provide a much better service if we have more information, and the devices and services downstream can make use of score data to decide how to present the call. >>>>> >>>>> Brian >>>>> >>>>> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan wrote: >>>>> >>>>>> >>>>>> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>>>>> >>>>>>> As I keep saying, over and over, what they are used for today is termination dips, where all you have to query with is the telephone number, and that gets poor scores. >>>>>> >>>>>> Yes, I know they're queried on termination; and yes, I know they're queried using the source telephone number. STIR will provide validity for that source number, so that you can't pretend to be a source number you aren't. That should make things better for calling names, if the content of the calling name databases is accurate. You've been claiming the content of the databases is fairly accurate. (and as far as I can tell, they have been relatively accurate so far, for at least CNAM databases though maybe not LIDB ones) >>>>>> >>>>>> I know many folks don't like the CNAM model, but I believe they don't like it due to the pricing model - not due to bad content, nor due to having to physically query it. They don't like the fact that the receiver of calls has to pay extra for getting data the far-end wanted to be delivered to begin with. >>>>>> >>>>>> I don't know what you mean by "that gets poor scores". As far as I know, there is no such thing as a "score" in the existing PSTN calling name market. There are name/number/phone-service "types" or category, but not scores of name accuracy afaik. Are there such things? Why would anyone claim their score is anything but perfect? >>>>>> >>>>>> >>>>>>> What we need is to do the dip at the origination side, where you have more information to make the score larger, and securely carry it in the SIP signaling. That is the problem to be solved - I have the name, the score, and the identity of the validator. I have to get that information across reliably, and reliably includes preventing messing with it at the origination side (so the sender can't lie about the score). >>>>>> >>>>>> I think that jumps to a solution - presumably the problem is "calling names aren't reliable"; the problem is not "we can't send scores securely in SIP". >>>>>> >>>>>> This whole topic is reminiscent of the debates the SIPPING WG had years ago on: >>>>>> draft-wing-sipping-spam-score >>>>>> draft-schwartz-sipping-spit-saml >>>>>> >>>>>> -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 Wed Aug 28 10:34: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 3472A21F99B8 for ; Wed, 28 Aug 2013 10:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.172 X-Spam-Level: X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=0.427, 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 Cgn7EQOnmbKG for ; Wed, 28 Aug 2013 10:34:06 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5842B11E81B8 for ; Wed, 28 Aug 2013 10:34:06 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so4453325oag.4 for ; Wed, 28 Aug 2013 10:34:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=XEPAOwKlocEqqKvrvmf7uNdnrFAxt9iZmrv66dMRHNo=; b=Cgqbrhh92b70ByaM6GLF4/2fCqJ+tdvWYjvAtL96nsv9YFsWcU5Z9G9frEXV65BsTD vUvvebOpJsJO0XSV4NaGew4O3q9IvhnNHNJ9NLOoX+8xLWB2qQZVaD1HJZM4VtR+swI1 hYSI9Eg0frifCIUrlq+IDvHoB68CwVRFMKsFM2epLAtNgoe50LuTuxATKTUuqveoAMvd BwiTlSEuEL8Tem3yfzyAm0FMo3Kl2kabXvtkdiTHpWqerNQJoviUBw2UQoHGlx3wriui jFsCKxhfHzGym0C0r3zE6z5cceUUqJkTUcSJFlZZya65VZlqhuSvgR//kEwzfC5ljovT GDgQ== X-Gm-Message-State: ALoCoQnh3VfdCF2AdQOIz2Ej7my1KMboTZIOHvYNsaEfsyyEhSUaohTBE3ypqCTJFVJI8vTvipbH X-Received: by 10.60.56.3 with SMTP id w3mr16736834oep.37.1377711244848; Wed, 28 Aug 2013 10:34:04 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id ru3sm26949849obc.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 10:34:03 -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: <521E2EC4.9070805@alum.mit.edu> Date: Wed, 28 Aug 2013 13:34:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org 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: Wed, 28 Aug 2013 17:34:11 -0000 On Aug 28, 2013, at 1:09 PM, Paul Kyzivat wrote: > On 8/28/13 11:31 AM, Brian Rosen wrote: >> I'll try to step through this carefully. >=20 > Thanks. >=20 >> 1. Assume stir credentials assigned, so sending SP has credential for = +12125551212 >=20 > And this is independent of the (name) validation service, right? Yes >=20 >> 2. At service initiation sending SP gets name and other info from its = subscriber. >=20 > So a key point is that the validation service is not in the call path. > It doesn't have the same real-time constraints. Yes >=20 >> It sends info to its chosen validation service (with number), and = receives a score and a signature in response. Re-validation is done = periodically, say months. >=20 > What is signed? Number+name+score? Yes > ISTM that such a signature attests to the combination signed, and in = particular that the score pertains to the other signed information. > I don't see how it would make sense for information that isn't signed = to affect the score. Take, for example, address. The database has address. If you pass name = + number + address than the score is likely higher than if you just had = name + number. Or, it could be something like prior addresses, or = prior phone number, or home phone if the phone number you are validating = is a mobile number. All of these fields are in the database, and the more you provide, the = higher the score would be, assuming it's correct. >=20 > Or do you intend that the other info sent to the validator is proof = that the requester is the holder of the credential for the number? > (In lieu of including that in calls.) No, it's proof that the name being asserted is correct. The database = has a record with dozens of fields. You can supply as many fields as = you have on the query. The score represents the likelihood that given = all that data, the database has the correct record, and the name = associated with that record is correct. >=20 >> 3. At call time, sending SP puts name in display name part of = From/P-A-I, and includes score and signature in stir header (and = probably a digest of the name, so the name can be munged and have the = stir header check work) >> 4. Receiver SP verifies signature in stir header >> 5. Receiver SP verifies signature of validator, which has a well = known credential >> 6. Based on score, receiver SP decides how to populate display name = for recipient device, or it may pass the score to the receiver device = for display. >=20 > ISTM that you can achieve the same effect by putting a signed number = and an unsigned name in the call. The recipient then verifies the = signature on the number. Then it takes the name and number and requests = a score from a validator. Well, yes, you could do that, although you have to pass the id of the = validator (because there are more than one of them), and you have to do = a data dip on the recipient side. As proposed, there is no dip. You = get everything you need, since the credential of the validator is well = known. If there is a dip, you can get the name and the score and the signature. = I'm proposing there is no dip. >=20 > This requires the validator in the call path. But the receiving SP can = cache these and build its own DB. >=20 > Thanks, > Paul >=20 >> Brian >> On Aug 28, 2013, at 10:30 AM, Paul Kyzivat = wrote: >>=20 >>> Brian, >>>=20 >>> OK, clearly I don't understand what you are proposing. Can you = explain it better? >>>=20 >>> On one hand I think you are assuming a service that can be queried = with a bunch of factors, and returns a confidence score that that = combination of factors is valid. E.g., I might present a name and number = and get a score. Or I might present a name, number, and some other = secrets known to the caller, and get a score. >>>=20 >>> Assuming there is some value in using that extra information, and = assuming the extra information is something that the caller doesn't want = to share with the callee, then I see why the caller would need to do the = query rather than the callee. >>>=20 >>> How is that to be communicated to the callee? You seen to say that = the service will return some sort of signed object that the recipient = can understand. Presumably that object must include the name, number, = and score in some crypto-protected form. I guess this means that the = request must be of the form: please score (number,name,x,y,z) and return = the score in cert showing only (number,name,score). This is presumably = possible, though it seems a bit weird. >>>=20 >>> My problem with the above is that you suggest that giving more = information will get a higher score. I don't understand why. If the = name/number combination is valid, then its valid. How much better can it = get than that? Any increased score due to more inputs being correct only = pertains to the extra attributes, not the name/number. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 8/28/13 9:52 AM, Brian Rosen wrote: >>>>=20 >>>> On Aug 27, 2013, at 9:35 PM, Paul Kyzivat = wrote: >>>>=20 >>>>> Brian, >>>>>=20 >>>>> Like Hadriel, I'm not getting your point about the score, and what = having a bunch of factors says about the score. >>>>>=20 >>>>> I can see that if I'm trying to enroll with some naming service = that they would want to get a bunch of facts from me to verify I am who = I say I am. And if I have less facts then they are less certain who I = am. That could enter into a score they give when queried. >>>> Yes >>>>>=20 >>>>> But I don't see what that has to do with this problem. >>>>>=20 >>>>> One possibility is that the originator of the call always uses one = name per phone number, in which case getting the name by looking up the = phone number is fine. In that case, the score depends on what facts were = given when the name was assigned to the number in the db. The lookup can = be done by the recipient without loss of function. >>>> You missed the part where we proposed that the name comes in the = signaling from the sender. >>>>=20 >>>> There is no lookup by phone number. >>>>=20 >>>> We could do that, but the proposal is to change the CNAM mechanism = to carry the name in the signaling. >>>>=20 >>>> The score would come in the signaling. The recipient gets a name, = and it gets the score, and it gets a signature of one of a small number = of validators that asserts the score. It then can evaluate, based on = it's trust in the validator, and the score, what to display to the user. >>>>=20 >>>> To be clear, it is possible to do something like send the id of the = validator in the signaling, and then query the validator at the = recipient with the phone number to get the name and the score. That = would be equivalent to what I propose, but it isn't what I'm proposing. >>>>=20 >>>>>=20 >>>>> Another possibility is that the originator wants the option of = using multiple names with the same number. (One for any given call.) For = that to work, I guess all the possible names for a number must be = enrolled. And presumably each of them get a score. In this case the = phone number isn't sufficient to lookup the name. But the caller could = include the name in the signaling, and the recipient could provide both = the name and number for lookup. Then I would succeed, with a score, if = that is one of the enrolled names for the number. Else it would fail. >>>> Not proposing multiple names per number >>>>=20 >>>>>=20 >>>>> Another possibility is that signing of names is entirely = independent of the signing of numbers, with possibly different entities = doing it. In that case I agree that the recipient looking up the number = won't give the same result. This seems something like a SAML system. >>>> The proposal is that the name is signed by one of a small number of = name validators, and those are independent of the number delegation = based credentials issued to sign the number. I just replied to Hadriel = with the explanation of why I propose we mix them (because the name = validation is done infrequently, and is used for multiple calls, so to = prevent cut/paste, we cover it with the per-call number signature). >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>> On 8/27/13 6:49 PM, Brian Rosen wrote: >>>>>> We're proposing to change CNAM in a couple of ways: >>>>>> 1. We're proposing to move the name determination from the = termination to the origination >>>>>> 2. We're proposing to send a score >>>>>>=20 >>>>>> We think the score can be used very effectively by the = termination. It can be used with a threshold, and the threshold can be = set by the termination service provider to match what service level it = offers. More interestingly, it can be used by the termination device to = display some useful data to the consumer that is not black or white. >>>>>>=20 >>>>>> We want the score to be as accurate as it can be. The databases = have dozens of fields, not all of which are populated for every record. = The more fields you provide, the more accurate the score is (and the = higher the score gets). If all you query with is name and phone number, = the confidence level is medium to low. If you have more data, like = address for example, the confidence is considerably higher. It's not = that address is better, it's that if you have a match of name AND number = AND address, you have a much smaller error. >>>>>>=20 >>>>>> The databases we have today use scores. >>>>>>=20 >>>>>> Just as an example, my company has such a database. It has = dozens of fields. One of the products that is driven by the database is = a CNAM service. When the termination side dips the database, it does so = only with the telephone number. The scores are fairly low, but there = is a threshold (I don't actually know the details). You get a name, or = no entry found out of that dip. The database scores the data and = applies a threshold to it. >>>>>>=20 >>>>>> The exact same database is used for a call center caller match = query. You call the call center, the operator asks your name and = address, gets phone number from ANI and they query the database (same = database) to get a score of how likely the data in the query matches = (name and phone number and address match each other). The service you = get depends on that score. >>>>>>=20 >>>>>> We can provide a much better service if we have more information, = and the devices and services downstream can make use of score data to = decide how to present the call. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On Aug 27, 2013, at 4:41 PM, Brian Rosen = wrote: >>>>>>>=20 >>>>>>>> As I keep saying, over and over, what they are used for today = is termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>>>>>>=20 >>>>>>> Yes, I know they're queried on termination; and yes, I know = they're queried using the source telephone number. STIR will provide = validity for that source number, so that you can't pretend to be a = source number you aren't. That should make things better for calling = names, if the content of the calling name databases is accurate. You've = been claiming the content of the databases is fairly accurate. (and as = far as I can tell, they have been relatively accurate so far, for at = least CNAM databases though maybe not LIDB ones) >>>>>>>=20 >>>>>>> I know many folks don't like the CNAM model, but I believe they = don't like it due to the pricing model - not due to bad content, nor due = to having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>>>>>>=20 >>>>>>> I don't know what you mean by "that gets poor scores". As far = as I know, there is no such thing as a "score" in the existing PSTN = calling name market. There are name/number/phone-service "types" or = category, but not scores of name accuracy afaik. Are there such things? = Why would anyone claim their score is anything but perfect? >>>>>>>=20 >>>>>>>=20 >>>>>>>> What we need is to do the dip at the origination side, where = you have more information to make the score larger, and securely carry = it in the SIP signaling. That is the problem to be solved - I have the = name, the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>>>>>>=20 >>>>>>> I think that jumps to a solution - presumably the problem is = "calling names aren't reliable"; the problem is not "we can't send = scores securely in SIP". >>>>>>>=20 >>>>>>> This whole topic is reminiscent of the debates the SIPPING WG = had years ago on: >>>>>>> draft-wing-sipping-spam-score >>>>>>> draft-schwartz-sipping-spit-saml >>>>>>>=20 >>>>>>> -hadriel >>>>>>>=20 >>>>>>=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 Henning.Schulzrinne@fcc.gov Wed Aug 28 10:50:32 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 B6C1711E81AF for ; Wed, 28 Aug 2013 10:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 q10YK11TQvO4 for ; Wed, 28 Aug 2013 10:50:27 -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 73F6311E8196 for ; Wed, 28 Aug 2013 10:50:27 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' , Paul Kyzivat Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAADT0cAAAAyOIAAA4HxgAAA8nIAAAXKhIAAGcErgAABT20AAAIgCoAAA25tAAAA3BeAAAhOx6A= Date: Wed, 28 Aug 2013 17:50:24 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> In-Reply-To: <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.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" 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: Wed, 28 Aug 2013 17:50:32 -0000 Based on what I've seen, the score is an indicator of confidence by the thi= rd party in the information presented. Thus, presumably a self-asserted nam= e would get a score of 0, and somebody that the validator has checked out p= ersonally for a security clearance would get a high-90s score. At least in the systems I've been told about, this does *not* depend on the= amount of information provided, although you could obviously have differen= t confidence scores for different parts. For example, a wireline service pr= ovider would have high confidence in the service address, possibly low conf= idence in the name of a residential subscriber (depending on, for example, = the credit card information agrees with that name or not). To make this simple, one model I envision ("by value") would have "[call to 213 555 1234 at 13:48] service address is at 123 Main St. [95%]; = name is Dewey, Cheatem & Howe, LLP [60%]." {signed: Verizon, carrier} As I've mentioned earlier, in many (business-identifying) cases, for third-= party assertions, you don't really need any new SIP additions or signatures= , just a way to reliably associate a phone number with an assertion record.= This doesn't work well for residential numbers, for the obvious privacy re= asons, since you've just created an inverse white pages for everybody. The = ARID Internet Draft I mentioned avoids this problem and doesn't require any= new PKI. Henning From pkyzivat@alum.mit.edu Wed Aug 28 10:55: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 E601411E81D2 for ; Wed, 28 Aug 2013 10:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.327 X-Spam-Level: X-Spam-Status: No, score=-0.327 tagged_above=-999 required=5 tests=[AWL=0.110, 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 jnCI-LwmdjGt for ; Wed, 28 Aug 2013 10:55:19 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id CF3E011E81CA for ; Wed, 28 Aug 2013 10:55:09 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id JCLQ1m0011c6gX85CHv9q0; Wed, 28 Aug 2013 17:55:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id JHv91m00C3ZTu2S3jHv9gy; Wed, 28 Aug 2013 17:55:09 +0000 Message-ID: <521E397C.4020408@alum.mit.edu> Date: Wed, 28 Aug 2013 13:55:08 -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: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> In-Reply-To: <49CBF97B-4171-4512-BFDC-600D88347191@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=1377712509; bh=sLM4YXA7pod7ssZJesWQ8l5rmLVkNervCI/9zNALO/8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iF5ikj/oA4muDnE4VBp6roHa2oQ36zID1jW7FX0WjE8peU8ZQX/d4xOGjlXeAbSJp mYhBJtlMcGfjWu6jbz7CujLDeFE6Ikf/s8OQilvVrt7Y96WWnEK4JuesHi/gFu1Suw ebVt9Rr/MiOf1kzAffUl+Xlwy3GYMfFOIcayXeoW9qYSM4OdgfP5/AMUgP2XLcAZl8 PdWAIodiehfdYrgUnLvMw0ATN220ZnPa9+j6aLnx4dpFgk0+78/9x25A0kBqqvPsKj 8KhRBLb87NgSPan7CL//C6eO6VrBMe7ZJJNB/gpPdyIaqTDSgFTRr6sgNUA1PbM6MT MkYY+1g0wnlTQ== Cc: cnit@ietf.org 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: Wed, 28 Aug 2013 17:55:58 -0000 On 8/28/13 1:34 PM, Brian Rosen wrote: >> What is signed? Number+name+score? > Yes >> ISTM that such a signature attests to the combination signed, and in particular that the score pertains to the other signed information. >> I don't see how it would make sense for information that isn't signed to affect the score. > Take, for example, address. The database has address. If you pass name + number + address than the score is likely higher than if you just had name + number. Or, it could be something like prior addresses, or prior phone number, or home phone if the phone number you are validating is a mobile number. > > All of these fields are in the database, and the more you provide, the higher the score would be, assuming it's correct. Sorry. I'm still not getting it. Why is the score higher, and if so, is that relevant to the callee? What is the score measuring? You seem to assume that this DB has a bunch of entries, and the score measures how closely the query matches exactly one entry. But that isn't interesting here. All the caller wants to know is how likely it is that the name is associated with the number. What else the caller knows about the db entry is not relevant to the callee. Thanks, Paul From br@brianrosen.net Wed Aug 28 11:01:07 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 9FA8D21F98AD for ; Wed, 28 Aug 2013 11:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 pJOtsmSzdNuG for ; Wed, 28 Aug 2013 11:01:01 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id CDD7421F9EFB for ; Wed, 28 Aug 2013 11:01:00 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so7027819obc.20 for ; Wed, 28 Aug 2013 11:01:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=l3WsxlFUOkYYEZ47QjWuNaxBIy5E/BOyWQcgFOv1dRQ=; b=QgyukO8qSNz4uhV/F+XH8ChnIhRFnI5TgGNVJEG66CKBK5XHR8rJjWzcsCeUCmNz31 sB6owdBqhenmnZLiuwcE4TEIDgsvQtYoVvcd5KFKyN/NQ5xZmXIIhZE89kg9HHKVwTfI aStkacDXUoQkBesvRziv+QdD4vmT8Yt/vL7XymT7+uzWAA5nMqMw3s3TSRCKrp9bNRmW 0i15Aa9jDfNkPa5AJhIRtqoTzQsYjSpEiaVV2ZDOaux0q8dLeqhtX2CTDA92bc2wlytq hfE6fOkcpXj8reHVuIiwcQhNusSeyAb7J6ySYklFpcX/EH3f10xQwjnsxLv32DePGyK1 QRRw== X-Gm-Message-State: ALoCoQkBs9rCkU7heL3KruaZb+BfrPQxPgm54hXeadyT+S95SZHAF8UUnW+64ADcMgbpInfRDOVi X-Received: by 10.182.243.138 with SMTP id wy10mr5463480obc.83.1377712860386; Wed, 28 Aug 2013 11:01:00 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id uz16sm27076399obc.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 11:00:59 -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, 28 Aug 2013 14:00:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <95992695-B61B-4E1D-BA61-16AF5A3493C4@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Paul Kyzivat 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: Wed, 28 Aug 2013 18:01:07 -0000 In the systems I know, the more information that is presented, the = higher the likelihood field of interest is correct, because the sources = of the data vary a lot, and there are overlapping records. This arrises in consumer data because there is no single universal id to = use to construct an individual record for each actual person. =20 Brian On Aug 28, 2013, at 1:50 PM, Henning Schulzrinne = wrote: > Based on what I've seen, the score is an indicator of confidence by = the third party in the information presented. Thus, presumably a = self-asserted name would get a score of 0, and somebody that the = validator has checked out personally for a security clearance would get = a high-90s score. >=20 > At least in the systems I've been told about, this does *not* depend = on the amount of information provided, although you could obviously have = different confidence scores for different parts. For example, a wireline = service provider would have high confidence in the service address, = possibly low confidence in the name of a residential subscriber = (depending on, for example, the credit card information agrees with that = name or not). >=20 > To make this simple, one model I envision ("by value") would have >=20 > "[call to 213 555 1234 at 13:48] service address is at 123 Main St. = [95%]; name is Dewey, Cheatem & Howe, LLP [60%]." {signed: Verizon, = carrier} >=20 > As I've mentioned earlier, in many (business-identifying) cases, for = third-party assertions, you don't really need any new SIP additions or = signatures, just a way to reliably associate a phone number with an = assertion record. This doesn't work well for residential numbers, for = the obvious privacy reasons, since you've just created an inverse white = pages for everybody. The ARID Internet Draft I mentioned avoids this = problem and doesn't require any new PKI. >=20 > Henning From br@brianrosen.net Wed Aug 28 11:17:52 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 BC2A121E8050 for ; Wed, 28 Aug 2013 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 NzJp3XO73Iov for ; Wed, 28 Aug 2013 11:17:46 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id D607521F991F for ; Wed, 28 Aug 2013 11:17:46 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id o17so8272673oag.35 for ; Wed, 28 Aug 2013 11:17:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=u/8X9FF184UGzIix2qotMlgnBQfwpS1g8HQVC2hIu38=; b=AzGxiH5+o0ACOd9uh+Gesd6/0Limx82fRv0UJHDOp1SKu4hJv2BFUN4w9yq+BpK53a InIJ3Hvrq+655x6gc7QYksxxj6n/sZhbYRawiiBEQkJMQIaFGDnD1uIcv3Rivkcn2LLk TKMfqyaK+BcXnrEMsGSRsO5TSo7wM0TiYfqW30J+s/lYIGJwd6ipyo1vicnUxyTsii93 HK2bXVHotGlEgzByLwT2aTIytAwuZnjU2eO1xjgdZlMvfRxmO917+gYS04i8FfgGGQZL NTQwrX2f8opSkGDPmaeaEgN1Txx8L09zZlT2kOM1qMXaXjnaqVnRHVWU6rj8j+6Mqjjc iJlQ== X-Gm-Message-State: ALoCoQlm0zbwkzvvk1f9TPFUea/3xZh927uySVhMVmVxncs1NvsGIFj8XqORNQnF6ddEGKX5Hrm8 X-Received: by 10.60.95.40 with SMTP id dh8mr21784151oeb.20.1377713866327; Wed, 28 Aug 2013 11:17:46 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id uz16sm27158423obc.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 11:17:45 -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: <521E397C.4020408@alum.mit.edu> Date: Wed, 28 Aug 2013 14:17:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> <521E397C.4020408@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org 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: Wed, 28 Aug 2013 18:17:52 -0000 I'm getting to the limit of what I know about these systems, so I may = have to go back and find out more, but as I understand it, the = fundamental thing the database is scoring is how likely the set of data = presented represents a real person. Because there are many sources of = data going into the database, it isn't possible to know from a small set = of data, like a phone number, which records the database may have match. = The more data provided, the larger the ability of the database to = correlate what it knows and determine whether the information supplied = is good. So, indeed, if you gave it a good name, a good phone number and a bad = address, you likely would get a much lower score than if you just gave = it a good name and good phone number, but if you gave it a good name, a = good number AND a good address, you get a higher score, and the higher = score does mean that the name is more likely correct than if address was = not supplied. So the score really does represent what you want to see - it correlates = well to the probability the name is correct (since the address isn't = available to the recipient, all it has is the name and the number, and = it knows the number is correct). Brian On Aug 28, 2013, at 1:55 PM, Paul Kyzivat wrote: > On 8/28/13 1:34 PM, Brian Rosen wrote: >=20 >>> What is signed? Number+name+score? >> Yes >>> ISTM that such a signature attests to the combination signed, and in = particular that the score pertains to the other signed information. >>> I don't see how it would make sense for information that isn't = signed to affect the score. >> Take, for example, address. The database has address. If you pass = name + number + address than the score is likely higher than if you just = had name + number. Or, it could be something like prior addresses, or = prior phone number, or home phone if the phone number you are validating = is a mobile number. >>=20 >> All of these fields are in the database, and the more you provide, = the higher the score would be, assuming it's correct. >=20 > Sorry. I'm still not getting it. > Why is the score higher, and if so, is that relevant to the callee? >=20 > What is the score measuring? > You seem to assume that this DB has a bunch of entries, and the score = measures how closely the query matches exactly one entry. But that isn't = interesting here. >=20 > All the caller wants to know is how likely it is that the name is = associated with the number. What else the caller knows about the db = entry is not relevant to the callee. >=20 > Thanks, > Paul From Henning.Schulzrinne@fcc.gov Wed Aug 28 11:19: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 0DE4921F9FF6 for ; Wed, 28 Aug 2013 11:19:51 -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 s-omVYD6ljgF for ; Wed, 28 Aug 2013 11:19:42 -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 B626D21E8050 for ; Wed, 28 Aug 2013 11:19:39 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAADT0cAAAAyOIAAA4HxgAAA8nIAAAXKhIAAGcErgAABT20AAAIgCoAAA25tAAAA3BeAAAhOx6D//8UQgIAAQeow Date: Wed, 28 Aug 2013 18:17:56 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> <95992695-B61B-4E1D-BA61-16AF5A3493C4@brianrosen.net> In-Reply-To: <95992695-B61B-4E1D-BA61-16AF5A3493C4@brianrosen.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" , Paul Kyzivat 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: Wed, 28 Aug 2013 18:19:51 -0000 This contradicts what a large provider of such services told us, but your m= ileage and database may vary. (They base the confidence of a particular "is= the person filling out that webpage really the person they claim to be" tr= ansaction, a slightly different problem, on the amount of other information= , such as financial transactions, provided and verifiable. That may be what= you're referring to.) The additional information is *not* made available t= o anybody else. This is conceptually similar to the additional security que= stions that ask where your first pet was born. For our purposes, we really have two inter-related problems: (1) Who made this call? In other words, assume a near-perfect record of cal= l makers (humans and/or organizations), and identify one of them uniquely. = We all agree that names are a somewhat imperfect identifier, but clearly us= ed for other business transactions; there is no reason the identity for bus= inesses couldn't be some unique non-name identifier (like the DUN I mention= ed before). (2) Does the person have these attributes, such as name, address and busine= ss license, and how confident are we in each attribute? There are potential problems with both steps, such as the same physical per= son having multiple records and multiple people getting accidentally merged= into one record. (The latter is apparently a problem for credit records, w= ith not-so-pleasant outcomes.) This is probably less of an issue for busine= ss records, although some parts of the information may well be out of date = or never been correct. (For example, most small businesses only update thei= r state incorporation records once a year, so the address may be wrong, and= the state registrars don't validate the postal address beyond possibly che= cking the existence of the address.) Henning -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, August 28, 2013 2:01 PM To: Henning Schulzrinne Cc: Paul Kyzivat; cnit@ietf.org Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) In the systems I know, the more information that is presented, the higher t= he likelihood field of interest is correct, because the sources of the data= vary a lot, and there are overlapping records. This arrises in consumer data because there is no single universal id to us= e to construct an individual record for each actual person. =20 Brian On Aug 28, 2013, at 1:50 PM, Henning Schulzrinne wrote: > Based on what I've seen, the score is an indicator of confidence by the t= hird party in the information presented. Thus, presumably a self-asserted n= ame would get a score of 0, and somebody that the validator has checked out= personally for a security clearance would get a high-90s score. >=20 > At least in the systems I've been told about, this does *not* depend on t= he amount of information provided, although you could obviously have differ= ent confidence scores for different parts. For example, a wireline service = provider would have high confidence in the service address, possibly low co= nfidence in the name of a residential subscriber (depending on, for example= , the credit card information agrees with that name or not). >=20 > To make this simple, one model I envision ("by value") would have >=20 > "[call to 213 555 1234 at 13:48] service address is at 123 Main St. [95%]= ; name is Dewey, Cheatem & Howe, LLP [60%]." {signed: Verizon, carrier} >=20 > As I've mentioned earlier, in many (business-identifying) cases, for thir= d-party assertions, you don't really need any new SIP additions or signatur= es, just a way to reliably associate a phone number with an assertion recor= d. This doesn't work well for residential numbers, for the obvious privacy = reasons, since you've just created an inverse white pages for everybody. Th= e ARID Internet Draft I mentioned avoids this problem and doesn't require a= ny new PKI. >=20 > Henning From alex@bobotek.net Wed Aug 28 11:24:33 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 7E7A321F9ECA for ; Wed, 28 Aug 2013 11:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 cDEvQy4xPTet for ; Wed, 28 Aug 2013 11:24:28 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id BC6C221F9AA8 for ; Wed, 28 Aug 2013 11:24:08 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta09.emeryville.ca.mail.comcast.net with comcast id JDJv1m0070S2fkCA9JQ8r4; Wed, 28 Aug 2013 18:24:08 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta09.emeryville.ca.mail.comcast.net with comcast id JJQ71m0044EJ4tY8VJQ7li; Wed, 28 Aug 2013 18:24:08 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Wed, 28 Aug 2013 11:16:27 -0700 From: Alex Bobotek To: Brian Rosen , Paul Kyzivat Date: Wed, 28 Aug 2013 11:16:25 -0700 Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6j9OcN66/UATfURF20CHs4ITzJpAAFlF1Q Message-ID: <4B1956260CD29F4A9622F00322FE053193812973E1@BOBO1A.bobotek.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> In-Reply-To: <15603CA4-534A-4CCB-9EC4-9EFFD17B8B47@brianrosen.net> 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377714248; bh=ACOWIOElIMOi8EtyiTB8YICH5rfUufcloqtbbSEkGgw=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=fWJOrk8EYZPOiwzpsHjKiEJMx7C2d80qtrok13BSt88Rzlckzrb1Le/dbZsfFesKb calp19W6+0mpT51IiLqRXfe7ftiK09S/u5fuSPG/62NdxwCoDumMcjCO0RF45wRDik hY0MzDB34W1ndMn+BxpolR9UhSipVrYiH7v3gpVTp6LPqpuRl6RVPBZB9nEYlsWJ1B jhkAw2e96nrhDUmjzjS32VkfBRmK1QFlneMUp4SgNPjINaT0kB87Q/pInV7QAkvvyy dWd5M88fFlTHfAXFsKj7MAVlwqhZor/ooE3wWhTFME896PNmQHbcz3/Q9i+xvcyQV8 CQTfzFsiqzt8w== Cc: "cnit@ietf.org" 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: Wed, 28 Aug 2013 18:24:33 -0000 I support the notion of _permitting_ an originating service provider to pre= sent the strength of their subscriber authentication (e.g., drivers license= presented, no auth, etc.) or other indicators of trust. But asking an ori= ginating service provider to generate and attach a score of its own custome= rs is problematic from a business perspective. What, short of regulation, = would motivate competing service providers to attach anything but a stellar= score? =20 Scoring should be adding in signaling transit and/or added at the terminati= ng end. =20 Terminating service providers are unlikely to value scores calculated using= a formula that allows the originating service provider to inject unwarrant= ed trust. =20 Most of reputation assessment should be performed by a party other than the= originating service provider. =20 Regards, Alex -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Wednesday, August 28, 2013 6:53 AM To: Paul Kyzivat Cc: cnit@ietf.org Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) On Aug 27, 2013, at 9:35 PM, Paul Kyzivat wrote: > Brian, >=20 > Like Hadriel, I'm not getting your point about the score, and what having= a bunch of factors says about the score. >=20 > I can see that if I'm trying to enroll with some naming service that they= would want to get a bunch of facts from me to verify I am who I say I am. = And if I have less facts then they are less certain who I am. That could en= ter into a score they give when queried. Yes >=20 > But I don't see what that has to do with this problem. >=20 > One possibility is that the originator of the call always uses one name p= er phone number, in which case getting the name by looking up the phone num= ber is fine. In that case, the score depends on what facts were given when = the name was assigned to the number in the db. The lookup can be done by th= e recipient without loss of function. You missed the part where we proposed that the name comes in the signaling = from the sender. There is no lookup by phone number. We could do that, but the proposal is to change the CNAM mechanism to carry= the name in the signaling. The score would come in the signaling. The recipient gets a name, and it g= ets the score, and it gets a signature of one of a small number of validato= rs that asserts the score. It then can evaluate, based on it's trust in th= e validator, and the score, what to display to the user. To be clear, it is possible to do something like send the id of the validat= or in the signaling, and then query the validator at the recipient with th= e phone number to get the name and the score. That would be equivalent to = what I propose, but it isn't what I'm proposing. >=20 > Another possibility is that the originator wants the option of using mult= iple names with the same number. (One for any given call.) For that to work= , I guess all the possible names for a number must be enrolled. And presuma= bly each of them get a score. In this case the phone number isn't sufficien= t to lookup the name. But the caller could include the name in the signalin= g, and the recipient could provide both the name and number for lookup. The= n I would succeed, with a score, if that is one of the enrolled names for t= he number. Else it would fail. Not proposing multiple names per number >=20 > Another possibility is that signing of names is entirely independent of t= he signing of numbers, with possibly different entities doing it. In that c= ase I agree that the recipient looking up the number won't give the same re= sult. This seems something like a SAML system. The proposal is that the name is signed by one of a small number of name va= lidators, and those are independent of the number delegation based credenti= als issued to sign the number. I just replied to Hadriel with the explanat= ion of why I propose we mix them (because the name validation is done infre= quently, and is used for multiple calls, so to prevent cut/paste, we cover = it with the per-call number signature). >=20 > Thanks, > Paul >=20 > On 8/27/13 6:49 PM, Brian Rosen wrote: >> We're proposing to change CNAM in a couple of ways: >> 1. We're proposing to move the name determination from the=20 >> termination to the origination 2. We're proposing to send a score >>=20 >> We think the score can be used very effectively by the termination. It = can be used with a threshold, and the threshold can be set by the terminati= on service provider to match what service level it offers. More interestin= gly, it can be used by the termination device to display some useful data t= o the consumer that is not black or white. >>=20 >> We want the score to be as accurate as it can be. The databases have do= zens of fields, not all of which are populated for every record. The more = fields you provide, the more accurate the score is (and the higher the scor= e gets). If all you query with is name and phone number, the confidence le= vel is medium to low. If you have more data, like address for example, the= confidence is considerably higher. It's not that address is better, it's = that if you have a match of name AND number AND address, you have a much sm= aller error. >>=20 >> The databases we have today use scores. >>=20 >> Just as an example, my company has such a database. It has dozens of fi= elds. One of the products that is driven by the database is a CNAM service= . When the termination side dips the database, it does so only with the te= lephone number. The scores are fairly low, but there is a threshold (I do= n't actually know the details). You get a name, or no entry found out of t= hat dip. The database scores the data and applies a threshold to it. >>=20 >> The exact same database is used for a call center caller match query. Y= ou call the call center, the operator asks your name and address, gets phon= e number from ANI and they query the database (same database) to get a scor= e of how likely the data in the query matches (name and phone number and ad= dress match each other). The service you get depends on that score. >>=20 >> We can provide a much better service if we have more information, and th= e devices and services downstream can make use of score data to decide how = to present the call. >>=20 >> Brian >>=20 >> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>=20 >>>=20 >>> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>>=20 >>>> As I keep saying, over and over, what they are used for today is termi= nation dips, where all you have to query with is the telephone number, and = that gets poor scores. >>>=20 >>> Yes, I know they're queried on termination; and yes, I know they're=20 >>> queried using the source telephone number. STIR will provide=20 >>> validity for that source number, so that you can't pretend to be a=20 >>> source number you aren't. That should make things better for=20 >>> calling names, if the content of the calling name databases is=20 >>> accurate. You've been claiming the content of the databases is=20 >>> fairly accurate. (and as far as I can tell, they have been=20 >>> relatively accurate so far, for at least CNAM databases though maybe=20 >>> not LIDB ones) >>>=20 >>> I know many folks don't like the CNAM model, but I believe they don't l= ike it due to the pricing model - not due to bad content, nor due to having= to physically query it. They don't like the fact that the receiver of cal= ls has to pay extra for getting data the far-end wanted to be delivered to = begin with. >>>=20 >>> I don't know what you mean by "that gets poor scores". As far as I kno= w, there is no such thing as a "score" in the existing PSTN calling name ma= rket. There are name/number/phone-service "types" or category, but not sco= res of name accuracy afaik. Are there such things? Why would anyone claim= their score is anything but perfect? >>>=20 >>>=20 >>>> What we need is to do the dip at the origination side, where you have = more information to make the score larger, and securely carry it in the SIP= signaling. That is the problem to be solved - I have the name, the score,= and the identity of the validator. I have to get that information across = reliably, and reliably includes preventing messing with it at the originati= on side (so the sender can't lie about the score). >>>=20 >>> I think that jumps to a solution - presumably the problem is "calling n= ames aren't reliable"; the problem is not "we can't send scores securely in= SIP". >>>=20 >>> This whole topic is reminiscent of the debates the SIPPING WG had years= ago on: >>> draft-wing-sipping-spam-score >>> draft-schwartz-sipping-spit-saml >>>=20 >>> -hadriel >>>=20 >>=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 _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From Henning.Schulzrinne@fcc.gov Wed Aug 28 11:41: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 E7D7E21E8083 for ; Wed, 28 Aug 2013 11:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 iDpIkLKROJxd for ; Wed, 28 Aug 2013 11:41: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 46E7B21E8063 for ; Wed, 28 Aug 2013 11:41:45 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Alex Bobotek' Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAADT0cAAAAyOIAAA4HxgAAA8nIAAAXKhIAAGcErgAAJNRGAAAfdLDA= Date: Wed, 28 Aug 2013 18:41:43 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> In-Reply-To: <4B1956260CD29F4A9622F00322FE053193812973E1@BOBO1A.bobotek.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" 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: Wed, 28 Aug 2013 18:41:59 -0000 I suspect we all agree that this would be optional, by everybody. (In other= words, end users and carriers should be able to decide *not* to do this.) Given the much larger number of legitimate carriers than Experian/D&B-style= third-party databases, I tend to agree with you that a simple declaration = of fact ("user-asserted", "billing record", "service address") is likely to= be more useful than a score. I don't see how any non-zero score presented = by carrier A would be comparable to that by carrier B, even assuming both a= re of the most upstanding kind with no interest in score inflation. For the small number of large third-party databases, this will likely be so= mewhat like credit scores - the number itself doesn't measure anything in p= articular (not meters, not total debt), but recipients will associate certa= in values with their risk tolerance. ("If we get a TrustUs score below 39, = we don't believe the caller ID. For Neustar, we cut off at 52.") Some carriers may want to offer value-added services, where they attach a t= hird-party assertion to business-originated calls. ("This call came from Ge= neral Motors, claimed by TrustUs Business Directory to be located in Detroi= t, MI and in the automotive business.") It is logistically much easier for = a large carrier to get a dip agreement for a third-party database such as t= he business databases I've been using as examples than for the recipient. -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Ale= x Bobotek Sent: Wednesday, August 28, 2013 2:16 PM To: Brian Rosen; Paul Kyzivat Cc: cnit@ietf.org Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) I support the notion of _permitting_ an originating service provider to pre= sent the strength of their subscriber authentication (e.g., drivers license= presented, no auth, etc.) or other indicators of trust. But asking an ori= ginating service provider to generate and attach a score of its own custome= rs is problematic from a business perspective. What, short of regulation, = would motivate competing service providers to attach anything but a stellar= score? =20 Scoring should be adding in signaling transit and/or added at the terminati= ng end. =20 Terminating service providers are unlikely to value scores calculated using= a formula that allows the originating service provider to inject unwarrant= ed trust. =20 Most of reputation assessment should be performed by a party other than the= originating service provider. =20 Regards, Alex -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Wednesday, August 28, 2013 6:53 AM To: Paul Kyzivat Cc: cnit@ietf.org Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) On Aug 27, 2013, at 9:35 PM, Paul Kyzivat wrote: > Brian, >=20 > Like Hadriel, I'm not getting your point about the score, and what having= a bunch of factors says about the score. >=20 > I can see that if I'm trying to enroll with some naming service that they= would want to get a bunch of facts from me to verify I am who I say I am. = And if I have less facts then they are less certain who I am. That could en= ter into a score they give when queried. Yes >=20 > But I don't see what that has to do with this problem. >=20 > One possibility is that the originator of the call always uses one name p= er phone number, in which case getting the name by looking up the phone num= ber is fine. In that case, the score depends on what facts were given when = the name was assigned to the number in the db. The lookup can be done by th= e recipient without loss of function. You missed the part where we proposed that the name comes in the signaling = from the sender. There is no lookup by phone number. We could do that, but the proposal is to change the CNAM mechanism to carry= the name in the signaling. The score would come in the signaling. The recipient gets a name, and it g= ets the score, and it gets a signature of one of a small number of validato= rs that asserts the score. It then can evaluate, based on it's trust in th= e validator, and the score, what to display to the user. To be clear, it is possible to do something like send the id of the validat= or in the signaling, and then query the validator at the recipient with th= e phone number to get the name and the score. That would be equivalent to = what I propose, but it isn't what I'm proposing. >=20 > Another possibility is that the originator wants the option of using mult= iple names with the same number. (One for any given call.) For that to work= , I guess all the possible names for a number must be enrolled. And presuma= bly each of them get a score. In this case the phone number isn't sufficien= t to lookup the name. But the caller could include the name in the signalin= g, and the recipient could provide both the name and number for lookup. The= n I would succeed, with a score, if that is one of the enrolled names for t= he number. Else it would fail. Not proposing multiple names per number >=20 > Another possibility is that signing of names is entirely independent of t= he signing of numbers, with possibly different entities doing it. In that c= ase I agree that the recipient looking up the number won't give the same re= sult. This seems something like a SAML system. The proposal is that the name is signed by one of a small number of name va= lidators, and those are independent of the number delegation based credenti= als issued to sign the number. I just replied to Hadriel with the explanat= ion of why I propose we mix them (because the name validation is done infre= quently, and is used for multiple calls, so to prevent cut/paste, we cover = it with the per-call number signature). >=20 > Thanks, > Paul >=20 > On 8/27/13 6:49 PM, Brian Rosen wrote: >> We're proposing to change CNAM in a couple of ways: >> 1. We're proposing to move the name determination from the=20 >> termination to the origination 2. We're proposing to send a score >>=20 >> We think the score can be used very effectively by the termination. It = can be used with a threshold, and the threshold can be set by the terminati= on service provider to match what service level it offers. More interestin= gly, it can be used by the termination device to display some useful data t= o the consumer that is not black or white. >>=20 >> We want the score to be as accurate as it can be. The databases have do= zens of fields, not all of which are populated for every record. The more = fields you provide, the more accurate the score is (and the higher the scor= e gets). If all you query with is name and phone number, the confidence le= vel is medium to low. If you have more data, like address for example, the= confidence is considerably higher. It's not that address is better, it's = that if you have a match of name AND number AND address, you have a much sm= aller error. >>=20 >> The databases we have today use scores. >>=20 >> Just as an example, my company has such a database. It has dozens of fi= elds. One of the products that is driven by the database is a CNAM service= . When the termination side dips the database, it does so only with the te= lephone number. The scores are fairly low, but there is a threshold (I do= n't actually know the details). You get a name, or no entry found out of t= hat dip. The database scores the data and applies a threshold to it. >>=20 >> The exact same database is used for a call center caller match query. Y= ou call the call center, the operator asks your name and address, gets phon= e number from ANI and they query the database (same database) to get a scor= e of how likely the data in the query matches (name and phone number and ad= dress match each other). The service you get depends on that score. >>=20 >> We can provide a much better service if we have more information, and th= e devices and services downstream can make use of score data to decide how = to present the call. >>=20 >> Brian >>=20 >> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>=20 >>>=20 >>> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>>=20 >>>> As I keep saying, over and over, what they are used for today is termi= nation dips, where all you have to query with is the telephone number, and = that gets poor scores. >>>=20 >>> Yes, I know they're queried on termination; and yes, I know they're=20 >>> queried using the source telephone number. STIR will provide=20 >>> validity for that source number, so that you can't pretend to be a=20 >>> source number you aren't. That should make things better for=20 >>> calling names, if the content of the calling name databases is=20 >>> accurate. You've been claiming the content of the databases is=20 >>> fairly accurate. (and as far as I can tell, they have been=20 >>> relatively accurate so far, for at least CNAM databases though maybe=20 >>> not LIDB ones) >>>=20 >>> I know many folks don't like the CNAM model, but I believe they don't l= ike it due to the pricing model - not due to bad content, nor due to having= to physically query it. They don't like the fact that the receiver of cal= ls has to pay extra for getting data the far-end wanted to be delivered to = begin with. >>>=20 >>> I don't know what you mean by "that gets poor scores". As far as I kno= w, there is no such thing as a "score" in the existing PSTN calling name ma= rket. There are name/number/phone-service "types" or category, but not sco= res of name accuracy afaik. Are there such things? Why would anyone claim= their score is anything but perfect? >>>=20 >>>=20 >>>> What we need is to do the dip at the origination side, where you have = more information to make the score larger, and securely carry it in the SIP= signaling. That is the problem to be solved - I have the name, the score,= and the identity of the validator. I have to get that information across = reliably, and reliably includes preventing messing with it at the originati= on side (so the sender can't lie about the score). >>>=20 >>> I think that jumps to a solution - presumably the problem is "calling n= ames aren't reliable"; the problem is not "we can't send scores securely in= SIP". >>>=20 >>> This whole topic is reminiscent of the debates the SIPPING WG had years= ago on: >>> draft-wing-sipping-spam-score >>> draft-schwartz-sipping-spit-saml >>>=20 >>> -hadriel >>>=20 >>=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 _______________________________________________ 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 Aug 28 11:43: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 3E3B321E8093 for ; Wed, 28 Aug 2013 11:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 g4YC9LOO+vKz for ; Wed, 28 Aug 2013 11:43:29 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF3721E8063 for ; Wed, 28 Aug 2013 11:43:17 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so8211848oag.2 for ; Wed, 28 Aug 2013 11:43:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=t5e3dEFr5/cgz6yjNB3uifVWmxpyx71niUYt/+1VlM0=; b=ahf2ZSYdes2Lt5sWq4Nz7TUMfMq6TGfp5bD1rPSOBSw3AjZkDh8fuBPHiQZ1EczFvK 0oOOIIk6PNHGDxWUJBAuUvNz9awr0wlshEAXy4nkjNhDIUqqsBdGzOED9wBuDL3iZsxp tnsl/cYbA4wqgfeV6DXweBVnVHULZ55LtvpgbEBFnVl662vWufHDzPPvp5JACmfu8VK2 VlhFcp1O6d77iXnOEoQohGltqCFBHbouV+im1oaPNyKmXIgaXVLEt6nyPh7QkIZd+BHj 4HNGQNftNz927Bq1n7Ppgmexkr87tmY4AxN7NrDfnwqIB4MIPaYoz8he8ZLu+IrcMkEI kTDg== X-Gm-Message-State: ALoCoQkqKoUk2WSzltnfjQi4WvL5t2iOCHaezuXogu0+cinLxWy0EbEEnUb8L1R2twnmHXrjmq13 X-Received: by 10.60.80.167 with SMTP id s7mr16264936oex.38.1377715395721; Wed, 28 Aug 2013 11:43:15 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id rl1sm28150591oeb.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 11:43:15 -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: <4B1956260CD29F4A9622F00322FE053193812973E1@BOBO1A.bobotek.net> Date: Wed, 28 Aug 2013 14:43:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> To: Alex Bobotek X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Paul Kyzivat 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: Wed, 28 Aug 2013 18:43:34 -0000 I'm suggesting the originating service provider seek a validation from a = 3rd party validator in most cases, although I wouldn't entirely rule = out having the originating SP do the validation itself if it has access = to enough data to do it well. The mechanism would not allow the = origination to tamper with the score or substitute a different score = from an unrelated number, or change the name associated with the = validation. Doing it at the termination side is no where near as good, because the = terminating side doesn't have enough information to get a good score. Brian On Aug 28, 2013, at 2:16 PM, Alex Bobotek wrote: > I support the notion of _permitting_ an originating service provider = to present the strength of their subscriber authentication (e.g., = drivers license presented, no auth, etc.) or other indicators of trust. = But asking an originating service provider to generate and attach a = score of its own customers is problematic from a business perspective. = What, short of regulation, would motivate competing service providers to = attach anything but a stellar score? =20 >=20 > Scoring should be adding in signaling transit and/or added at the = terminating end. =20 >=20 > Terminating service providers are unlikely to value scores calculated = using a formula that allows the originating service provider to inject = unwarranted trust. =20 >=20 > Most of reputation assessment should be performed by a party other = than the originating service provider. =20 >=20 > Regards, >=20 > Alex >=20 > -----Original Message----- > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Wednesday, August 28, 2013 6:53 AM > To: Paul Kyzivat > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual = caller ID) >=20 >=20 > On Aug 27, 2013, at 9:35 PM, Paul Kyzivat = wrote: >=20 >> Brian, >>=20 >> Like Hadriel, I'm not getting your point about the score, and what = having a bunch of factors says about the score. >>=20 >> I can see that if I'm trying to enroll with some naming service that = they would want to get a bunch of facts from me to verify I am who I say = I am. And if I have less facts then they are less certain who I am. That = could enter into a score they give when queried. > Yes >>=20 >> But I don't see what that has to do with this problem. >>=20 >> One possibility is that the originator of the call always uses one = name per phone number, in which case getting the name by looking up the = phone number is fine. In that case, the score depends on what facts were = given when the name was assigned to the number in the db. The lookup can = be done by the recipient without loss of function. > You missed the part where we proposed that the name comes in the = signaling from the sender. >=20 > There is no lookup by phone number. >=20 > We could do that, but the proposal is to change the CNAM mechanism to = carry the name in the signaling. >=20 > The score would come in the signaling. The recipient gets a name, and = it gets the score, and it gets a signature of one of a small number of = validators that asserts the score. It then can evaluate, based on it's = trust in the validator, and the score, what to display to the user. >=20 > To be clear, it is possible to do something like send the id of the = validator in the signaling, and then query the validator at the = recipient with the phone number to get the name and the score. That = would be equivalent to what I propose, but it isn't what I'm proposing. >=20 >>=20 >> Another possibility is that the originator wants the option of using = multiple names with the same number. (One for any given call.) For that = to work, I guess all the possible names for a number must be enrolled. = And presumably each of them get a score. In this case the phone number = isn't sufficient to lookup the name. But the caller could include the = name in the signaling, and the recipient could provide both the name and = number for lookup. Then I would succeed, with a score, if that is one of = the enrolled names for the number. Else it would fail. > Not proposing multiple names per number >=20 >>=20 >> Another possibility is that signing of names is entirely independent = of the signing of numbers, with possibly different entities doing it. In = that case I agree that the recipient looking up the number won't give = the same result. This seems something like a SAML system. > The proposal is that the name is signed by one of a small number of = name validators, and those are independent of the number delegation = based credentials issued to sign the number. I just replied to Hadriel = with the explanation of why I propose we mix them (because the name = validation is done infrequently, and is used for multiple calls, so to = prevent cut/paste, we cover it with the per-call number signature). >=20 >>=20 >> Thanks, >> Paul >>=20 >> On 8/27/13 6:49 PM, Brian Rosen wrote: >>> We're proposing to change CNAM in a couple of ways: >>> 1. We're proposing to move the name determination from the=20 >>> termination to the origination 2. We're proposing to send a score >>>=20 >>> We think the score can be used very effectively by the termination. = It can be used with a threshold, and the threshold can be set by the = termination service provider to match what service level it offers. = More interestingly, it can be used by the termination device to display = some useful data to the consumer that is not black or white. >>>=20 >>> We want the score to be as accurate as it can be. The databases = have dozens of fields, not all of which are populated for every record. = The more fields you provide, the more accurate the score is (and the = higher the score gets). If all you query with is name and phone number, = the confidence level is medium to low. If you have more data, like = address for example, the confidence is considerably higher. It's not = that address is better, it's that if you have a match of name AND number = AND address, you have a much smaller error. >>>=20 >>> The databases we have today use scores. >>>=20 >>> Just as an example, my company has such a database. It has dozens = of fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. >>>=20 >>> The exact same database is used for a call center caller match = query. You call the call center, the operator asks your name and = address, gets phone number from ANI and they query the database (same = database) to get a score of how likely the data in the query matches = (name and phone number and address match each other). The service you = get depends on that score. >>>=20 >>> We can provide a much better service if we have more information, = and the devices and services downstream can make use of score data to = decide how to present the call. >>>=20 >>> Brian >>>=20 >>> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>>=20 >>>>=20 >>>> On Aug 27, 2013, at 4:41 PM, Brian Rosen wrote: >>>>=20 >>>>> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>>>=20 >>>> Yes, I know they're queried on termination; and yes, I know they're=20= >>>> queried using the source telephone number. STIR will provide=20 >>>> validity for that source number, so that you can't pretend to be a=20= >>>> source number you aren't. That should make things better for=20 >>>> calling names, if the content of the calling name databases is=20 >>>> accurate. You've been claiming the content of the databases is=20 >>>> fairly accurate. (and as far as I can tell, they have been=20 >>>> relatively accurate so far, for at least CNAM databases though = maybe=20 >>>> not LIDB ones) >>>>=20 >>>> I know many folks don't like the CNAM model, but I believe they = don't like it due to the pricing model - not due to bad content, nor due = to having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>>>=20 >>>> I don't know what you mean by "that gets poor scores". As far as I = know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >>>>=20 >>>>=20 >>>>> What we need is to do the dip at the origination side, where you = have more information to make the score larger, and securely carry it in = the SIP signaling. That is the problem to be solved - I have the name, = the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>>>=20 >>>> I think that jumps to a solution - presumably the problem is = "calling names aren't reliable"; the problem is not "we can't send = scores securely in SIP". >>>>=20 >>>> This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: >>>> draft-wing-sipping-spam-score >>>> draft-schwartz-sipping-spit-saml >>>>=20 >>>> -hadriel >>>>=20 >>>=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 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From pkyzivat@alum.mit.edu Wed Aug 28 11:44:29 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 E40E021F9BF3 for ; Wed, 28 Aug 2013 11:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=0.109, 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 SIWqQLYFLFyI for ; Wed, 28 Aug 2013 11:44:24 -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 000F221F9B6A for ; Wed, 28 Aug 2013 11:44:23 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta06.westchester.pa.mail.comcast.net with comcast id JB9z1m00C0xGWP856JkPqv; Wed, 28 Aug 2013 18:44:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id JJkP1m00E3ZTu2S3YJkPe8; Wed, 28 Aug 2013 18:44:23 +0000 Message-ID: <521E4506.70706@alum.mit.edu> Date: Wed, 28 Aug 2013 14:44:22 -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: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> <95992695-B61B-4E1D-BA61-16AF5A3493C4@brianrosen.net> In-Reply-To: <95992695-B61B-4E1D-BA61-16AF5A3493C4@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=1377715463; bh=lNVZIcjCGZXo5bJuW+Wjm20PlSW4t1eLcVEP4qD2Alo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QAa20gq4vnOrAzeIeSpzKMwx9gxn96f+Gz4IhPwA+BhLEWdVHDe1v9Vad5Y54PmaG zyMZbVTTJTxZBD88soVOy6T3fgfQh6qkcX0GztjkKxISimMdVvJS5dsZrDW2fbrLDP KorrsGVj9Y2KGZBtF6ZKv6wuNao57qhRD8hyR92Afx7GkZbDzhQELvrXegyIRjZvga yKTR4ahh4y2NTr7eUIpEPRP2Br7W4zIAVL0DMYC5ZksUhQRCwHgb/iB2P+Ec3uo7S4 aHelzd++t+XpEBcrpsUrr18UKDXocWdUCHhA264Cq1d2vwFu6Zyp2kZ4MAc8MIu+5T kPPW68WHtHO8A== Cc: "cnit@ietf.org" , Henning Schulzrinne 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: Wed, 28 Aug 2013 18:44:30 -0000 On 8/28/13 2:00 PM, Brian Rosen wrote: > In the systems I know, the more information that is presented, the higher the likelihood field of interest is correct, because the sources of the data vary a lot, and there are overlapping records. > This arises in consumer data because there is no single universal id to use to construct an individual record for each actual person. This is not my field, and I'm not a statistician either. But what you say above makes no sense to me. Suppose I query this DB with just a number and name. There might be 0,1, or >1 matching records in the DB. If there are zero matching records, then I expect a 0 score. If there is one matching entry, then I expect a score of 1. If there is more than one matching entry, I still expect a score of 1. Its an odd case, but irrelevant to me. That assumes the DB has total confidence in the info it contains. If not, then the score can be reduced to reflect the confidence in the name. If there are multiple matching entries, and the confidence level in the name varies from one to another, then I guess the confidence level in the result must be some combination of the values from the multiple records. And in *this* case, having more information can reduce the match to a single record, and then to a single confidence level for the name. But frankly this sounds like nonsense to me. What is a real world example of this? Trying to construct an example: 1) name=foo, number=+12125551212, address="1 main st.", confidence=.75 2) name=foo, number=+12125551212, address="2 state st.", confidence=.25 3) name=bar, number=+12125551212, address="2 state st.", confidence=.10 If I query with name and number there are two matches. The confidence I get in the result is some combination of .75 and .25. It is really debatable whether I should get the max, min, or average, or even something greater than the max. Should the presence of an entry that matches the number and not the name reduce the score? Now suppose the caller does the query and also provides the address, matching (2). Does that mean the confidence level in the name should be .25? The callee doesn't get the address, so its correctness is irrelevant to him. This all seems dubious to me. Thanks, Paul > Brian > > On Aug 28, 2013, at 1:50 PM, Henning Schulzrinne wrote: > >> Based on what I've seen, the score is an indicator of confidence by the third party in the information presented. Thus, presumably a self-asserted name would get a score of 0, and somebody that the validator has checked out personally for a security clearance would get a high-90s score. >> >> At least in the systems I've been told about, this does *not* depend on the amount of information provided, although you could obviously have different confidence scores for different parts. For example, a wireline service provider would have high confidence in the service address, possibly low confidence in the name of a residential subscriber (depending on, for example, the credit card information agrees with that name or not). >> >> To make this simple, one model I envision ("by value") would have >> >> "[call to 213 555 1234 at 13:48] service address is at 123 Main St. [95%]; name is Dewey, Cheatem & Howe, LLP [60%]." {signed: Verizon, carrier} >> >> As I've mentioned earlier, in many (business-identifying) cases, for third-party assertions, you don't really need any new SIP additions or signatures, just a way to reliably associate a phone number with an assertion record. This doesn't work well for residential numbers, for the obvious privacy reasons, since you've just created an inverse white pages for everybody. The ARID Internet Draft I mentioned avoids this problem and doesn't require any new PKI. >> >> Henning > > From pkyzivat@alum.mit.edu Wed Aug 28 11:52: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 6497221F99A1 for ; Wed, 28 Aug 2013 11:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.107, 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 SUCm0cLXnV7D for ; Wed, 28 Aug 2013 11:52:29 -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 D718821F99C0 for ; Wed, 28 Aug 2013 11:52:27 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta06.westchester.pa.mail.comcast.net with comcast id JCLZ1m00517dt5G56JsPjp; Wed, 28 Aug 2013 18:52:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id JJsN1m01A3ZTu2S3ZJsPoH; Wed, 28 Aug 2013 18:52:23 +0000 Message-ID: <521E46E6.3000007@alum.mit.edu> Date: Wed, 28 Aug 2013 14:52:22 -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: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> <95992695-B61B-4E1D-BA61-16AF5A3493C4@brianrosen.net> 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=1377715943; bh=8O5ujPmd5YXF+UtcvNTQYLiBohYg0NHNsmMzku6A/Yc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ICBVulYDHBmyF/dG6X9iEkiDamcnVOqv45cX3LX0JlBfaODyXm9ZegmKuYkpsMo6b gTEgCuQElZgSyH5vm3x2aZrpJJiIhwsaCZ3JBircUjg1IdtuNZOc7KZnqSZWE8l9WX YTVm2axCRT+o3iN912CwlGwxYbMpTcvRGlcTWL3e23Zejxms4/sP1IR++4b1Dm8Y4/ DybgHNVmiUuVz8P2Avk6grS7Jwy5xDo3VpnW6QrYU/Ew556NeSHBcFKExVYtqSKUaS zXWq2vXEWV+D4eueJVSb2HUJjQNriAa0GQGQD3SfOEGXUptYFnmNrvVt/2O64g8l6T /CnLJBlu02/HQ== Cc: "cnit@ietf.org" , '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: Wed, 28 Aug 2013 18:52:35 -0000 On 8/28/13 2:17 PM, Henning Schulzrinne wrote: > This contradicts what a large provider of such services told us, but your mileage and database may vary. (They base the confidence of a particular "is the person filling out that webpage really the person they claim to be" transaction, a slightly different problem, on the amount of other information, such as financial transactions, provided and verifiable. That may be what you're referring to.) The additional information is *not* made available to anybody else. This is conceptually similar to the additional security questions that ask where your first pet was born. > > For our purposes, we really have two inter-related problems: > > (1) Who made this call? In other words, assume a near-perfect record of call makers (humans and/or organizations), and identify one of them uniquely. We all agree that names are a somewhat imperfect identifier, but clearly used for other business transactions; there is no reason the identity for businesses couldn't be some unique non-name identifier (like the DUN I mentioned before). But we can simplify this problem by reducing it to "what number made this call?" > (2) Does the person have these attributes, such as name, address and business license, and how confident are we in each attribute? Then this becomes "does this number have these attributes?" From Brian's comments it seems that many of the DBs out there aren't designed to answer precisely this last question. But it also seems that a DB to do that could be derived from them. > There are potential problems with both steps, such as the same physical person having multiple records and multiple people getting accidentally merged into one record. (The latter is apparently a problem for credit records, with not-so-pleasant outcomes.) This is probably less of an issue for business records, although some parts of the information may well be out of date or never been correct. (For example, most small businesses only update their state incorporation records once a year, so the address may be wrong, and the state registrars don't validate the postal address beyond possibly checking the existence of the address.) > > Henning > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, August 28, 2013 2:01 PM > To: Henning Schulzrinne > Cc: Paul Kyzivat; cnit@ietf.org > Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID) > > In the systems I know, the more information that is presented, the higher the likelihood field of interest is correct, because the sources of the data vary a lot, and there are overlapping records. > This arrises in consumer data because there is no single universal id to use to construct an individual record for each actual person. > > Brian > > On Aug 28, 2013, at 1:50 PM, Henning Schulzrinne wrote: > >> Based on what I've seen, the score is an indicator of confidence by the third party in the information presented. Thus, presumably a self-asserted name would get a score of 0, and somebody that the validator has checked out personally for a security clearance would get a high-90s score. >> >> At least in the systems I've been told about, this does *not* depend on the amount of information provided, although you could obviously have different confidence scores for different parts. For example, a wireline service provider would have high confidence in the service address, possibly low confidence in the name of a residential subscriber (depending on, for example, the credit card information agrees with that name or not). >> >> To make this simple, one model I envision ("by value") would have >> >> "[call to 213 555 1234 at 13:48] service address is at 123 Main St. [95%]; name is Dewey, Cheatem & Howe, LLP [60%]." {signed: Verizon, carrier} >> >> As I've mentioned earlier, in many (business-identifying) cases, for third-party assertions, you don't really need any new SIP additions or signatures, just a way to reliably associate a phone number with an assertion record. This doesn't work well for residential numbers, for the obvious privacy reasons, since you've just created an inverse white pages for everybody. The ARID Internet Draft I mentioned avoids this problem and doesn't require any new PKI. >> >> Henning > > From br@brianrosen.net Wed Aug 28 12:24:54 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 3AB8821F8EB5 for ; Wed, 28 Aug 2013 12:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.22 X-Spam-Level: X-Spam-Status: No, score=-103.22 tagged_above=-999 required=5 tests=[AWL=0.379, 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 CO7SYtvSgMw6 for ; Wed, 28 Aug 2013 12:24:41 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 053F521E809C for ; Wed, 28 Aug 2013 12:24:29 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id cm18so663571qab.15 for ; Wed, 28 Aug 2013 12:24:22 -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=P7OesWuQI3ZnP0QLRUnViRm6E3JiJiKcyXDAkN/JpqA=; b=Dl/sqVUfycdwXf9aSIsFlJCrsDpjaqxq5SmC2xCducVvelPkE7dPzvAON6mO6TPXnk 5dluPy9HhcPf5P+Aa/Vv8gLDnntNfMWM3LB/pdpkvg3bKgLOAoYvOvrakS1VptX3X9jm HCiw9Ijf97Xcq1uz5+igy652DkWreT18552AHeVuM/2MwjTN7nCCMYbGk8ZuZIst3iFf UURm6Phu9JTB9JeMLibDnx+OqK2L7cm6ta6kYDcMvA9GyHGyjFSEFw+Jv1RwiVbvTcru gWkwMTwriwOlDdAHfF1rgPZk6BpxlXAFMl4r1MMKdh+w/wA/YZjiuvMdABf5uVwq4MCn /HSw== X-Gm-Message-State: ALoCoQmgnTegZIV1jFCRtZB1Say1rv/xmtxfTYyfgp/PzVWvILu49HHweStPHqHJeMBPXzPJHbmX X-Received: by 10.224.138.8 with SMTP id y8mr302235qat.27.1377717861967; Wed, 28 Aug 2013 12:24:21 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 9sm38701606qau.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 12:24:20 -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: <521E4506.70706@alum.mit.edu> Date: Wed, 28 Aug 2013 15:24:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <00124C74-B98E-4918-BDD2-C48EC7C08B71@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> <95992695-B61B-4E1D-BA61-16AF5A3493C4@brianrosen.net> <521E4506.70706@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Henning Schulzrinne 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: Wed, 28 Aug 2013 19:24:54 -0000 On Aug 28, 2013, at 2:44 PM, Paul Kyzivat wrote: > On 8/28/13 2:00 PM, Brian Rosen wrote: >> In the systems I know, the more information that is presented, the = higher the likelihood field of interest is correct, because the sources = of the data vary a lot, and there are overlapping records. >> This arises in consumer data because there is no single universal id = to use to construct an individual record for each actual person. >=20 > This is not my field, and I'm not a statistician either. > But what you say above makes no sense to me. >=20 > Suppose I query this DB with just a number and name. > There might be 0,1, or >1 matching records in the DB. >=20 > If there are zero matching records, then I expect a 0 score. > If there is one matching entry, then I expect a score of 1. No. The system would probably give this a fairly low score because it = does't have much to go on. It would have one match, but that's a pretty = low. =20 >=20 > If there is more than one matching entry, I still expect a score of 1. = Its an odd case, but irrelevant to me. No, it's the common case. The database gets data from a wide variety of = sources. For example, it may have billing data from a utility provider, login = data from a website, property records from a public real estate = database, and drivers license data for some states. In each of these, it may or may not have an address, may or may not have = a phone number, and the name may be the same or similar. The more = similarities and correlated data, the higher the confidence it has in = the data. It tries to match records, but it doesn't know that it has an = exact match, so it uses statistics. When you query it with a small = amount of data, it gets some records that may have weak correlation, but = if you add data, then the correlation between the records is increased. >=20 > That assumes the DB has total confidence in the info it contains. > If not, then the score can be reduced to reflect the confidence in the = name. It's more like the more correlation of the data from multiple sources, = the higher its confidence. It does actually take into account where the = data comes from, but, as I understand it, it favors recurring data (same = name/number/address) over the source of the data. >=20 > If there are multiple matching entries, and the confidence level in = the name varies from one to another, then I guess the confidence level = in the result must be some combination of the values from the multiple = records. And in *this* case, having more information can reduce the = match to a single record, and then to a single confidence level for the = name. But frankly this sounds like nonsense to me. What is a real world = example of this? >=20 > Trying to construct an example: >=20 > 1) name=3Dfoo, number=3D+12125551212, address=3D"1 main st.", = confidence=3D.75 > 2) name=3Dfoo, number=3D+12125551212, address=3D"2 state st.", = confidence=3D.25 > 3) name=3Dbar, number=3D+12125551212, address=3D"2 state st.", = confidence=3D.10 I don't know enough how to tell you how it handles this. It probably = would be easier to understand if you assumed there were 10 or 20 source = records that had only 2 or 3 big discrepancies (foo vs bar and 1 main vs = 2 state). As I understand it, no record source is really considered = golden, so a range of .1 to .75 is probably overstating the range of = source reliability assumed. It would favor foo and 2 state st., but I = think the score for name would be pretty low with these data. >=20 > If I query with name and number there are two matches. The confidence = I get in the result is some combination of .75 and .25. It is really = debatable whether I should get the max, min, or average, or even = something greater than the max. Should the presence of an entry that = matches the number and not the name reduce the score? If you just queried with number and asked for name, it would give you = foo, and a low score. In most use cases, the database doesn't actually = give you any field content. It just gives you the score. The database = we run grew out of the CNAM database, so we still will give that data = out for that service, but most users can't query for field contents, = only score. >=20 > Now suppose the caller does the query and also provides the address, = matching (2). Does that mean the confidence level in the name should be = .25? The callee doesn't get the address, so its correctness is = irrelevant to him. The caller queries with all three. The score will be higher (assuming = we have a match) with 3 items in the query than it will be with two = (name and number) or one (just number) which is all the termination = could query with if we use the current model. The score will be very = low if you send us all three data items and we have none, or only a = small number of source records that match. >=20 > This all seems dubious to me. >=20 It works for a whole lot of use cases. It should work pretty well here. = No guarantees though. Nature of the name game. From hadriel.kaplan@oracle.com Thu Aug 29 06:46:45 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 9D12A21F9E02 for ; Thu, 29 Aug 2013 06:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 nAUBMi0UB-80 for ; Thu, 29 Aug 2013 06:46:35 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 544C121F9DC7 for ; Thu, 29 Aug 2013 06:46:32 -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 r7TDk79c021885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Aug 2013 13:46:07 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TDk5ji026835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 13:46:06 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TDk5ad026826; Thu, 29 Aug 2013 13:46:05 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Aug 2013 06:46:05 -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: <00124C74-B98E-4918-BDD2-C48EC7C08B71@brianrosen.net> Date: Thu, 29 Aug 2013 09:46:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01A880D9-4181-451C-8B32-F27FC69DE147@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <521E097A.6010508@alum.mit.edu> <02E32E0F-C731-47D7-AC48-4D0E015D9437@brianrosen.net> <521E2EC4.9070805@alum.mit.edu> <49CBF97B-4171-4512-BFDC-600D88347191@brianrosen.net> <95992695-B61B-4E1D-BA61-16AF5A3493C4@brianrosen.net> <521E4506.70706@alum.mit.edu> <00124C74-B98E-4918-BDD2-C48EC7C08B71@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "cnit@ietf.org" , Paul Kyzivat , Henning Schulzrinne 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: Thu, 29 Aug 2013 13:46:45 -0000 I think a lot of these multi-source needs for your particular = implementation arose because you weren't on the originating side, but = were doing it as a third party CNAM DB for the termination, no? I think = a verification provider working for the originating carriers - being = paid by them - wouldn't bother with most of these extra data sources. = If they wanted to have a good reputation, they might require more than = just the originating carrier's claim, but probably not much more. Regardless, I think the "score" thing is a bad idea - at least as = described so far. It doesn't matter what the verification service = thinks the score is, it matters what the call receivers can do with that = information. If they don't have a relationship with the verification = service (which is the basic premise of this model to begin with), then I = don't see how they'd really know what a score of 72 vs. 63 means. I = think the *verification service* should be the one deciding what their = own score means, by deciding whether their internal score is at a = sufficient threshold to be a usably reliable name for others or not, and = thus asserting it or not. Telling other people a score is just a = cop-out and going to cause interop problems in terms of actual = usability. If you really want this type of thing, I suggest following Verisign's = "Class" type model for certificates, since at least it might be defined = well enough for other people to figure out usages for. And we might = want to ask some folks from that world how successful that has been and = if it had issues or not. (I don't know) -hadriel On Aug 28, 2013, at 3:24 PM, Brian Rosen wrote: >=20 > On Aug 28, 2013, at 2:44 PM, Paul Kyzivat = wrote: >=20 >> On 8/28/13 2:00 PM, Brian Rosen wrote: >>> In the systems I know, the more information that is presented, the = higher the likelihood field of interest is correct, because the sources = of the data vary a lot, and there are overlapping records. >>> This arises in consumer data because there is no single universal id = to use to construct an individual record for each actual person. >>=20 >> This is not my field, and I'm not a statistician either. >> But what you say above makes no sense to me. >>=20 >> Suppose I query this DB with just a number and name. >> There might be 0,1, or >1 matching records in the DB. >>=20 >> If there are zero matching records, then I expect a 0 score. >> If there is one matching entry, then I expect a score of 1. > No. The system would probably give this a fairly low score because it = does't have much to go on. It would have one match, but that's a pretty = low. =20 >>=20 >> If there is more than one matching entry, I still expect a score of = 1. Its an odd case, but irrelevant to me. > No, it's the common case. The database gets data from a wide variety = of sources. >=20 > For example, it may have billing data from a utility provider, login = data from a website, property records from a public real estate = database, and drivers license data for some states. >=20 > In each of these, it may or may not have an address, may or may not = have a phone number, and the name may be the same or similar. The more = similarities and correlated data, the higher the confidence it has in = the data. It tries to match records, but it doesn't know that it has an = exact match, so it uses statistics. When you query it with a small = amount of data, it gets some records that may have weak correlation, but = if you add data, then the correlation between the records is increased. >>=20 >> That assumes the DB has total confidence in the info it contains. >> If not, then the score can be reduced to reflect the confidence in = the name. > It's more like the more correlation of the data from multiple sources, = the higher its confidence. It does actually take into account where the = data comes from, but, as I understand it, it favors recurring data (same = name/number/address) over the source of the data. >=20 >>=20 >> If there are multiple matching entries, and the confidence level in = the name varies from one to another, then I guess the confidence level = in the result must be some combination of the values from the multiple = records. And in *this* case, having more information can reduce the = match to a single record, and then to a single confidence level for the = name. But frankly this sounds like nonsense to me. What is a real world = example of this? >>=20 >> Trying to construct an example: >>=20 >> 1) name=3Dfoo, number=3D+12125551212, address=3D"1 main st.", = confidence=3D.75 >> 2) name=3Dfoo, number=3D+12125551212, address=3D"2 state st.", = confidence=3D.25 >> 3) name=3Dbar, number=3D+12125551212, address=3D"2 state st.", = confidence=3D.10 > I don't know enough how to tell you how it handles this. It probably = would be easier to understand if you assumed there were 10 or 20 source = records that had only 2 or 3 big discrepancies (foo vs bar and 1 main vs = 2 state). As I understand it, no record source is really considered = golden, so a range of .1 to .75 is probably overstating the range of = source reliability assumed. It would favor foo and 2 state st., but I = think the score for name would be pretty low with these data. >=20 >>=20 >> If I query with name and number there are two matches. The confidence = I get in the result is some combination of .75 and .25. It is really = debatable whether I should get the max, min, or average, or even = something greater than the max. Should the presence of an entry that = matches the number and not the name reduce the score? > If you just queried with number and asked for name, it would give you = foo, and a low score. In most use cases, the database doesn't actually = give you any field content. It just gives you the score. The database = we run grew out of the CNAM database, so we still will give that data = out for that service, but most users can't query for field contents, = only score. >=20 >>=20 >> Now suppose the caller does the query and also provides the address, = matching (2). Does that mean the confidence level in the name should be = .25? The callee doesn't get the address, so its correctness is = irrelevant to him. > The caller queries with all three. The score will be higher (assuming = we have a match) with 3 items in the query than it will be with two = (name and number) or one (just number) which is all the termination = could query with if we use the current model. The score will be very = low if you send us all three data items and we have none, or only a = small number of source records that match. >=20 >>=20 >> This all seems dubious to me. >>=20 > It works for a whole lot of use cases. It should work pretty well = here. No guarantees though. >=20 > Nature of the name game. >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From hadriel.kaplan@oracle.com Thu Aug 29 06:47:21 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 5282521F9EB5 for ; Thu, 29 Aug 2013 06:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 8b5ki4tzKxxw for ; Thu, 29 Aug 2013 06:47:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3D63221F9E48 for ; Thu, 29 Aug 2013 06:47:15 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7TDl9sK023046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Aug 2013 13:47:10 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TDl8SL010600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 13:47:09 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TDl8ZG010899; Thu, 29 Aug 2013 13:47:08 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Aug 2013 06:47:08 -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: Thu, 29 Aug 2013 09:47:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5CD91A23-CB33-47B6-9173-A8C5B62F7E40@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "cnit@ietf.org" , Alex Bobotek , Paul Kyzivat 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: Thu, 29 Aug 2013 13:47:21 -0000 ISTM the "score" shouldn't be put in a separate SIP header or param by = the carrier - it should be inside the signed "package" thingy, because = it's the verification service who's claiming this score, and the = verification service that therefore has to sign the {name, number, = score} package. The originating carrier isn't the one generating this = thing itself. This "score" discussion is getting us off-track though, I think. It = doesn't matter what one specific vendor's features or implementation = model is - it doesn't even matter whether we think some future CNIT = mechanism should use a "score" concept to begin with. All we need to know right now is if CNIT needs to have some blob signed = by STIR. I don't think it does, and no one seems to be arguing = otherwise. Even at a 10,000 foot view level, STIR is only signing enough stuff to = prevent cut-and-paste attacks of the source calling number. So long as = CNIT ties itself to the source number somehow, we don't need to sign it = with the STIR SIP signature. And if CNIT doesn't tie itself to the = source number, signing it with STIR doesn't prevent CNIT from being = cut-paste by others. -hadriel On Aug 28, 2013, at 2:43 PM, Brian Rosen wrote: > I'm suggesting the originating service provider seek a validation from = a 3rd party validator in most cases, although I wouldn't entirely rule = out having the originating SP do the validation itself if it has access = to enough data to do it well. The mechanism would not allow the = origination to tamper with the score or substitute a different score = from an unrelated number, or change the name associated with the = validation. >=20 > Doing it at the termination side is no where near as good, because the = terminating side doesn't have enough information to get a good score. >=20 > Brian >=20 > On Aug 28, 2013, at 2:16 PM, Alex Bobotek wrote: >=20 >> I support the notion of _permitting_ an originating service provider = to present the strength of their subscriber authentication (e.g., = drivers license presented, no auth, etc.) or other indicators of trust. = But asking an originating service provider to generate and attach a = score of its own customers is problematic from a business perspective. = What, short of regulation, would motivate competing service providers to = attach anything but a stellar score? =20 >>=20 >> Scoring should be adding in signaling transit and/or added at the = terminating end. =20 >>=20 >> Terminating service providers are unlikely to value scores calculated = using a formula that allows the originating service provider to inject = unwarranted trust. =20 >>=20 >> Most of reputation assessment should be performed by a party other = than the originating service provider. =20 >>=20 >> Regards, >>=20 >> Alex >>=20 >> -----Original Message----- >> From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf = Of Brian Rosen >> Sent: Wednesday, August 28, 2013 6:53 AM >> To: Paul Kyzivat >> Cc: cnit@ietf.org >> Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual = caller ID) >>=20 >>=20 >> On Aug 27, 2013, at 9:35 PM, Paul Kyzivat = wrote: >>=20 >>> Brian, >>>=20 >>> Like Hadriel, I'm not getting your point about the score, and what = having a bunch of factors says about the score. >>>=20 >>> I can see that if I'm trying to enroll with some naming service that = they would want to get a bunch of facts from me to verify I am who I say = I am. And if I have less facts then they are less certain who I am. That = could enter into a score they give when queried. >> Yes >>>=20 >>> But I don't see what that has to do with this problem. >>>=20 >>> One possibility is that the originator of the call always uses one = name per phone number, in which case getting the name by looking up the = phone number is fine. In that case, the score depends on what facts were = given when the name was assigned to the number in the db. The lookup can = be done by the recipient without loss of function. >> You missed the part where we proposed that the name comes in the = signaling from the sender. >>=20 >> There is no lookup by phone number. >>=20 >> We could do that, but the proposal is to change the CNAM mechanism to = carry the name in the signaling. >>=20 >> The score would come in the signaling. The recipient gets a name, = and it gets the score, and it gets a signature of one of a small number = of validators that asserts the score. It then can evaluate, based on = it's trust in the validator, and the score, what to display to the user. >>=20 >> To be clear, it is possible to do something like send the id of the = validator in the signaling, and then query the validator at the = recipient with the phone number to get the name and the score. That = would be equivalent to what I propose, but it isn't what I'm proposing. >>=20 >>>=20 >>> Another possibility is that the originator wants the option of using = multiple names with the same number. (One for any given call.) For that = to work, I guess all the possible names for a number must be enrolled. = And presumably each of them get a score. In this case the phone number = isn't sufficient to lookup the name. But the caller could include the = name in the signaling, and the recipient could provide both the name and = number for lookup. Then I would succeed, with a score, if that is one of = the enrolled names for the number. Else it would fail. >> Not proposing multiple names per number >>=20 >>>=20 >>> Another possibility is that signing of names is entirely independent = of the signing of numbers, with possibly different entities doing it. In = that case I agree that the recipient looking up the number won't give = the same result. This seems something like a SAML system. >> The proposal is that the name is signed by one of a small number of = name validators, and those are independent of the number delegation = based credentials issued to sign the number. I just replied to Hadriel = with the explanation of why I propose we mix them (because the name = validation is done infrequently, and is used for multiple calls, so to = prevent cut/paste, we cover it with the per-call number signature). >>=20 >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 8/27/13 6:49 PM, Brian Rosen wrote: >>>> We're proposing to change CNAM in a couple of ways: >>>> 1. We're proposing to move the name determination from the=20 >>>> termination to the origination 2. We're proposing to send a score >>>>=20 >>>> We think the score can be used very effectively by the termination. = It can be used with a threshold, and the threshold can be set by the = termination service provider to match what service level it offers. = More interestingly, it can be used by the termination device to display = some useful data to the consumer that is not black or white. >>>>=20 >>>> We want the score to be as accurate as it can be. The databases = have dozens of fields, not all of which are populated for every record. = The more fields you provide, the more accurate the score is (and the = higher the score gets). If all you query with is name and phone number, = the confidence level is medium to low. If you have more data, like = address for example, the confidence is considerably higher. It's not = that address is better, it's that if you have a match of name AND number = AND address, you have a much smaller error. >>>>=20 >>>> The databases we have today use scores. >>>>=20 >>>> Just as an example, my company has such a database. It has dozens = of fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. >>>>=20 >>>> The exact same database is used for a call center caller match = query. You call the call center, the operator asks your name and = address, gets phone number from ANI and they query the database (same = database) to get a score of how likely the data in the query matches = (name and phone number and address match each other). The service you = get depends on that score. >>>>=20 >>>> We can provide a much better service if we have more information, = and the devices and services downstream can make use of score data to = decide how to present the call. >>>>=20 >>>> Brian >>>>=20 >>>> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>>>=20 >>>>>=20 >>>>> On Aug 27, 2013, at 4:41 PM, Brian Rosen = wrote: >>>>>=20 >>>>>> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>>>>=20 >>>>> Yes, I know they're queried on termination; and yes, I know = they're=20 >>>>> queried using the source telephone number. STIR will provide=20 >>>>> validity for that source number, so that you can't pretend to be a=20= >>>>> source number you aren't. That should make things better for=20 >>>>> calling names, if the content of the calling name databases is=20 >>>>> accurate. You've been claiming the content of the databases is=20 >>>>> fairly accurate. (and as far as I can tell, they have been=20 >>>>> relatively accurate so far, for at least CNAM databases though = maybe=20 >>>>> not LIDB ones) >>>>>=20 >>>>> I know many folks don't like the CNAM model, but I believe they = don't like it due to the pricing model - not due to bad content, nor due = to having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>>>>=20 >>>>> I don't know what you mean by "that gets poor scores". As far as = I know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >>>>>=20 >>>>>=20 >>>>>> What we need is to do the dip at the origination side, where you = have more information to make the score larger, and securely carry it in = the SIP signaling. That is the problem to be solved - I have the name, = the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>>>>=20 >>>>> I think that jumps to a solution - presumably the problem is = "calling names aren't reliable"; the problem is not "we can't send = scores securely in SIP". >>>>>=20 >>>>> This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: >>>>> draft-wing-sipping-spam-score >>>>> draft-schwartz-sipping-spit-saml >>>>>=20 >>>>> -hadriel >>>>>=20 >>>>=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 >> _______________________________________________ >> 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 br@brianrosen.net Thu Aug 29 07:19: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 EF1E921F9DF0 for ; Thu, 29 Aug 2013 07:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.231 X-Spam-Level: X-Spam-Status: No, score=-103.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 IoREy5WNytSp for ; Thu, 29 Aug 2013 07:19:34 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7C42B21F9EB0 for ; Thu, 29 Aug 2013 07:19:32 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id k5so225698qej.36 for ; Thu, 29 Aug 2013 07:19:31 -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=AZ6WEyGj0Hu6Okeg21/qYWdgxujRug0H0f2L0MkHTm8=; b=W1HwXs7+1pVnXGnF2zeTy7yoXfm4BRp1h8CcFBKx9F6SSOZewgI+gU2eLnguberzYz hl70LniU893C9OwLh3ldF9HfefrymLYEchIi0zu7ZNEsoK3a1Fl7nRlp0ndSbruEpAGv Qo0SVBodM6vduguQAV4ki8XIW8EKB6zzsDtvu5DDJKJa0PO1VGfnQ8S3wVn2hpfJk8br sQEy5T1uri+ZUImGlseThFWsS0XRF4UNp9H1m6K73iErFmKryHArl/asENhoCJ4F+OVA Ft+Jfhb5s8nykL9Wnjjcvpnb4/3dAgMBdoTs3XJ355LooAV4X6rv6XsFloFF6y6+wNWs +H5g== X-Gm-Message-State: ALoCoQlNp1G0wujU5hbmsWz9Uje7RW/TRwo73HLeCN/esjFqXSiLrTAs1SUVaYWzLYsgpPy3ANUP X-Received: by 10.49.2.68 with SMTP id 4mr4110245qes.64.1377785971839; Thu, 29 Aug 2013 07:19:31 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id t4sm44492846qas.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 07:19:30 -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: <5CD91A23-CB33-47B6-9173-A8C5B62F7E40@oracle.com> Date: Thu, 29 Aug 2013 10:19:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7EB0D650-FFF9-459B-8D14-CBD09871D44B@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Alex Bobotek , Paul Kyzivat 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: Thu, 29 Aug 2013 14:19:39 -0000 The problem with names is that they aren't unique. So you can't get a = black/white answer to a question of "is this call coming from this guy". = Also true, but somewhat less so, for enterprise names. There, we have = better notions of what acceptable variations are, but we're subject to = some of the shenanigans of the UTF-8 variety. We also can't reliably = tie a name to another identity, so we can't attach a name to a number = with certainty. Scores deal with that reality. If you get rid of scores, you are losing = information. I think devices and services can usefully handle scores, = and if you want to threshold it, fine, do that. I have some sympathy with the inability to normalize scores. However, = it's reality - we don't have agreed upon metrics for these things. If = there are a small number of validators, then termination devices and = services can handle those differences, and we'll probably see some 4th = parties providing conversion services. The cnit package is probably best as a new header, with the score, the = validator identity and the signature as parameters. There isn't a good = reason to have it be a blob, repeating the number and the name for = example. We would have (a pretty simple) canonicalization of the name = in From/PAI, the score and the canonicalized number covered by the = signature. The validator ID could be a URI or a token from a registry. = The termination runs a process similar to the stir process - picks apart = From/PAI to extract the canonicalized name and number, takes the score = from the header and verifies the signature. Then it evaluates the score = knowing the validator to decide what to present to the user. I think you are probably right that IF the cnit package has the number, = and IF both cnit and stir headers (whatever they are) are present, then = the cut/paste protections of the stir signature prevent a cut/paste of = the cnit signature. The sender or observer could cut/paste a different = cnit package, but it would have to be tied to the number. Sending just the CNIT package without the STIR signature would allow a = cut/paste of the cnit package, but that's probably not a problem. Brian On Aug 29, 2013, at 9:47 AM, Hadriel Kaplan = wrote: >=20 > ISTM the "score" shouldn't be put in a separate SIP header or param by = the carrier - it should be inside the signed "package" thingy, because = it's the verification service who's claiming this score, and the = verification service that therefore has to sign the {name, number, = score} package. The originating carrier isn't the one generating this = thing itself. >=20 > This "score" discussion is getting us off-track though, I think. It = doesn't matter what one specific vendor's features or implementation = model is - it doesn't even matter whether we think some future CNIT = mechanism should use a "score" concept to begin with. >=20 > All we need to know right now is if CNIT needs to have some blob = signed by STIR. I don't think it does, and no one seems to be arguing = otherwise. >=20 > Even at a 10,000 foot view level, STIR is only signing enough stuff to = prevent cut-and-paste attacks of the source calling number. So long as = CNIT ties itself to the source number somehow, we don't need to sign it = with the STIR SIP signature. And if CNIT doesn't tie itself to the = source number, signing it with STIR doesn't prevent CNIT from being = cut-paste by others. >=20 > -hadriel >=20 >=20 > On Aug 28, 2013, at 2:43 PM, Brian Rosen wrote: >=20 >> I'm suggesting the originating service provider seek a validation = from a 3rd party validator in most cases, although I wouldn't entirely = rule out having the originating SP do the validation itself if it has = access to enough data to do it well. The mechanism would not allow the = origination to tamper with the score or substitute a different score = from an unrelated number, or change the name associated with the = validation. >>=20 >> Doing it at the termination side is no where near as good, because = the terminating side doesn't have enough information to get a good = score. >>=20 >> Brian >>=20 >> On Aug 28, 2013, at 2:16 PM, Alex Bobotek wrote: >>=20 >>> I support the notion of _permitting_ an originating service provider = to present the strength of their subscriber authentication (e.g., = drivers license presented, no auth, etc.) or other indicators of trust. = But asking an originating service provider to generate and attach a = score of its own customers is problematic from a business perspective. = What, short of regulation, would motivate competing service providers to = attach anything but a stellar score? =20 >>>=20 >>> Scoring should be adding in signaling transit and/or added at the = terminating end. =20 >>>=20 >>> Terminating service providers are unlikely to value scores = calculated using a formula that allows the originating service provider = to inject unwarranted trust. =20 >>>=20 >>> Most of reputation assessment should be performed by a party other = than the originating service provider. =20 >>>=20 >>> Regards, >>>=20 >>> Alex >>>=20 >>> -----Original Message----- >>> From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf = Of Brian Rosen >>> Sent: Wednesday, August 28, 2013 6:53 AM >>> To: Paul Kyzivat >>> Cc: cnit@ietf.org >>> Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual = caller ID) >>>=20 >>>=20 >>> On Aug 27, 2013, at 9:35 PM, Paul Kyzivat = wrote: >>>=20 >>>> Brian, >>>>=20 >>>> Like Hadriel, I'm not getting your point about the score, and what = having a bunch of factors says about the score. >>>>=20 >>>> I can see that if I'm trying to enroll with some naming service = that they would want to get a bunch of facts from me to verify I am who = I say I am. And if I have less facts then they are less certain who I = am. That could enter into a score they give when queried. >>> Yes >>>>=20 >>>> But I don't see what that has to do with this problem. >>>>=20 >>>> One possibility is that the originator of the call always uses one = name per phone number, in which case getting the name by looking up the = phone number is fine. In that case, the score depends on what facts were = given when the name was assigned to the number in the db. The lookup can = be done by the recipient without loss of function. >>> You missed the part where we proposed that the name comes in the = signaling from the sender. >>>=20 >>> There is no lookup by phone number. >>>=20 >>> We could do that, but the proposal is to change the CNAM mechanism = to carry the name in the signaling. >>>=20 >>> The score would come in the signaling. The recipient gets a name, = and it gets the score, and it gets a signature of one of a small number = of validators that asserts the score. It then can evaluate, based on = it's trust in the validator, and the score, what to display to the user. >>>=20 >>> To be clear, it is possible to do something like send the id of the = validator in the signaling, and then query the validator at the = recipient with the phone number to get the name and the score. That = would be equivalent to what I propose, but it isn't what I'm proposing. >>>=20 >>>>=20 >>>> Another possibility is that the originator wants the option of = using multiple names with the same number. (One for any given call.) For = that to work, I guess all the possible names for a number must be = enrolled. And presumably each of them get a score. In this case the = phone number isn't sufficient to lookup the name. But the caller could = include the name in the signaling, and the recipient could provide both = the name and number for lookup. Then I would succeed, with a score, if = that is one of the enrolled names for the number. Else it would fail. >>> Not proposing multiple names per number >>>=20 >>>>=20 >>>> Another possibility is that signing of names is entirely = independent of the signing of numbers, with possibly different entities = doing it. In that case I agree that the recipient looking up the number = won't give the same result. This seems something like a SAML system. >>> The proposal is that the name is signed by one of a small number of = name validators, and those are independent of the number delegation = based credentials issued to sign the number. I just replied to Hadriel = with the explanation of why I propose we mix them (because the name = validation is done infrequently, and is used for multiple calls, so to = prevent cut/paste, we cover it with the per-call number signature). >>>=20 >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>> On 8/27/13 6:49 PM, Brian Rosen wrote: >>>>> We're proposing to change CNAM in a couple of ways: >>>>> 1. We're proposing to move the name determination from the=20 >>>>> termination to the origination 2. We're proposing to send a score >>>>>=20 >>>>> We think the score can be used very effectively by the = termination. It can be used with a threshold, and the threshold can be = set by the termination service provider to match what service level it = offers. More interestingly, it can be used by the termination device to = display some useful data to the consumer that is not black or white. >>>>>=20 >>>>> We want the score to be as accurate as it can be. The databases = have dozens of fields, not all of which are populated for every record. = The more fields you provide, the more accurate the score is (and the = higher the score gets). If all you query with is name and phone number, = the confidence level is medium to low. If you have more data, like = address for example, the confidence is considerably higher. It's not = that address is better, it's that if you have a match of name AND number = AND address, you have a much smaller error. >>>>>=20 >>>>> The databases we have today use scores. >>>>>=20 >>>>> Just as an example, my company has such a database. It has dozens = of fields. One of the products that is driven by the database is a CNAM = service. When the termination side dips the database, it does so only = with the telephone number. The scores are fairly low, but there is a = threshold (I don't actually know the details). You get a name, or no = entry found out of that dip. The database scores the data and applies a = threshold to it. >>>>>=20 >>>>> The exact same database is used for a call center caller match = query. You call the call center, the operator asks your name and = address, gets phone number from ANI and they query the database (same = database) to get a score of how likely the data in the query matches = (name and phone number and address match each other). The service you = get depends on that score. >>>>>=20 >>>>> We can provide a much better service if we have more information, = and the devices and services downstream can make use of score data to = decide how to present the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Aug 27, 2013, at 6:22 PM, Hadriel Kaplan = wrote: >>>>>=20 >>>>>>=20 >>>>>> On Aug 27, 2013, at 4:41 PM, Brian Rosen = wrote: >>>>>>=20 >>>>>>> As I keep saying, over and over, what they are used for today is = termination dips, where all you have to query with is the telephone = number, and that gets poor scores. >>>>>>=20 >>>>>> Yes, I know they're queried on termination; and yes, I know = they're=20 >>>>>> queried using the source telephone number. STIR will provide=20 >>>>>> validity for that source number, so that you can't pretend to be = a=20 >>>>>> source number you aren't. That should make things better for=20 >>>>>> calling names, if the content of the calling name databases is=20 >>>>>> accurate. You've been claiming the content of the databases is=20= >>>>>> fairly accurate. (and as far as I can tell, they have been=20 >>>>>> relatively accurate so far, for at least CNAM databases though = maybe=20 >>>>>> not LIDB ones) >>>>>>=20 >>>>>> I know many folks don't like the CNAM model, but I believe they = don't like it due to the pricing model - not due to bad content, nor due = to having to physically query it. They don't like the fact that the = receiver of calls has to pay extra for getting data the far-end wanted = to be delivered to begin with. >>>>>>=20 >>>>>> I don't know what you mean by "that gets poor scores". As far as = I know, there is no such thing as a "score" in the existing PSTN calling = name market. There are name/number/phone-service "types" or category, = but not scores of name accuracy afaik. Are there such things? Why = would anyone claim their score is anything but perfect? >>>>>>=20 >>>>>>=20 >>>>>>> What we need is to do the dip at the origination side, where you = have more information to make the score larger, and securely carry it in = the SIP signaling. That is the problem to be solved - I have the name, = the score, and the identity of the validator. I have to get that = information across reliably, and reliably includes preventing messing = with it at the origination side (so the sender can't lie about the = score). >>>>>>=20 >>>>>> I think that jumps to a solution - presumably the problem is = "calling names aren't reliable"; the problem is not "we can't send = scores securely in SIP". >>>>>>=20 >>>>>> This whole topic is reminiscent of the debates the SIPPING WG had = years ago on: >>>>>> draft-wing-sipping-spam-score >>>>>> draft-schwartz-sipping-spit-saml >>>>>>=20 >>>>>> -hadriel >>>>>>=20 >>>>>=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 >>> _______________________________________________ >>> 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 From hadriel.kaplan@oracle.com Thu Aug 29 08:14:43 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 70C0421E80BC for ; Thu, 29 Aug 2013 08:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, GB_ABOUTYOU=0.5, 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 wKXbr7ky4p1h for ; Thu, 29 Aug 2013 08:14:38 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 96A6821E808E for ; Thu, 29 Aug 2013 08:12:28 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7TFBg9M001315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Aug 2013 15:11:43 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TFBfSH023939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 15:11:42 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TFBf3l023917; Thu, 29 Aug 2013 15:11:41 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Aug 2013 08:11:40 -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: <7EB0D650-FFF9-459B-8D14-CBD09871D44B@brianrosen.net> Date: Thu, 29 Aug 2013 11:11:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "cnit@ietf.org" , Alex Bobotek , Paul Kyzivat 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: Thu, 29 Aug 2013 15:14:43 -0000 On Aug 29, 2013, at 10:19 AM, Brian Rosen wrote: > The problem with names is that they aren't unique. So you can't get a = black/white answer to a question of "is this call coming from this guy". = Also true, but somewhat less so, for enterprise names. There, we have = better notions of what acceptable variations are, but we're subject to = some of the shenanigans of the UTF-8 variety.=20 Of course not. But that has nothing to do with a "score" given to = others. If you're claiming a name of "Brian Rosen", the fact that there = are other Brian Rosen's doesn't make your name more or less valid; nor = should it affect what a verification service tells others about your = name's validity. It might cause the verification service to find more = authentication factors to believe you, but that's the verification = service's job. At the end of the day, the whole point of a verification = service is to verify things. Putting the onus on everyone else to = decide how valid it is or not, based on scores, misses the whole point = of a verification service. Put this in the context of x.509 certificates and Certificate = Authorities. When you connect to "https://fidelity.com", the = certificate doesn't say "I'm 73% sure this is Fidelity". The closest = thing I can think of is Verisign's certificate Class model, where the = different classes define how "strong" the assertion is, based on how = much validation Verisign performed (among other things). I am *not* an = expert on how their classes truly get used, but as far as I know the = point of their classification system is to be used in different = contexts/applications. For example they have one sufficient for email, = separate from one sufficient for monetary business transactions. > We also can't reliably tie a name to another identity, so we can't = attach a name to a number with certainty. There's never such a thing as "certainty" obviously, but any assertion = about calling name identity must be claimed to be linked to a phone = number, because the calling number is all STIR provides. Having the = originator use its STIR-based private key to sign a name doesn't make = the name itself *valid*, nor does it mean the name is linked to the = phone number. For example, if you get a package with just {name=3D"Brian = Rosen",versig=3D" 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 0F97211E818B for ; Thu, 29 Aug 2013 16:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, GB_ABOUTYOU=0.5] 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 tI6NXap-cEmc for ; Thu, 29 Aug 2013 16:34:16 -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 2851711E8197 for ; Thu, 29 Aug 2013 16:34:15 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' , Brian Rosen Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAADT0cAAAAyOIAAA4HxgAAA8nIAAAXKhIAAGcErgAAJNRGAAADvA4AAJ/PcgAABIWKAAAHSaIAACB/Z0A== Date: Thu, 29 Aug 2013 23:33:43 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> 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] [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: Thu, 29 Aug 2013 23:34:20 -0000 As I've noted, I'm skeptical on numeric scores as well, but maybe it helps = to distinguish two sub-cases that we've been discussing: (1) plain display name, i.e., just a non-length-constrained version of toda= y's textual caller ID (2) more extensive description (address, line of business, BBB score, etc.) For pure names, I don't think scores help much, as this is really mostly ab= out where the information came from, if provided by a carrier. For names, g= etting back to roughly the "good old days" seems a good step forward, i.e.,= being able to tell who provided that information and generally being relia= ble. With a bit more effort, we can probably have four common cases that do= n't seem to impose any additional liability on carriers: (1) Name only, user asserted; might be signed by caller, but that simply pr= events third party munging (2) Name only, carrier asserted; possibly a separate signature, particularl= y if the number signature is done by the end user, as in {call-identifying information; 212 555 1212} [signed with E.164 key, but co= uld be signed by John Doe] {call-identifying information; John Doe; based on billing data} [signed by = Verizon] In this case, Verizon simply asserts "This is my customer and John Doe is t= he billing record". If the recipient has never heard of the signing party, = they may decide to ignore the signature. (3) Separate name and "Organization" header, common for organizations where= the carrier wouldn't really know who is the caller within the organization= and thus wouldn't want to sign for that. From: Martin Gecko Organization: GEICO Insurance Identity: {call identifiers, GEICO Insurance; based on=3Dbilling} [Verizon] Identity: {call identifiers, 1225551212} [GEICO] Identity: {call identifiers, Martin Gecko; based on=3Dassertion} [GEICO] In this case, having Verizon include the fingerprint of the GEICO cert wou= ld make this more useful. GEICO can provide an EV cert, if desired. (4) Signed Call-Info for more extensive information From: Martin Gecko Call-Info: http://www.trustus.com/GI8LvzC3mPWHwsioD Identity: {call identifiers, Call-Info content; based on=3Dthird-party} [Ve= rizon] It would be helpful if the recipient could ascertain that Verizon is respon= sible for the calling number, but this may not be strictly necessary if you= 're willing to take some lower-probability risks. Given the call identifyin= g information, only somebody on the call path could sign and cut-and-paste = doesn't seem to work. As far as I can tell, this doesn't force the carrier to take any additional= informational risk, but makes the source of the information explicit, rath= er than the "could be LIDB, could be some unknown CNAM, could be the caller= " guessing game of today. Henning -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Thursday, August 29, 2013 11:12 AM To: Brian Rosen Cc: cnit@ietf.org; Alex Bobotek; Paul Kyzivat Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) On Aug 29, 2013, at 10:19 AM, Brian Rosen wrote: > The problem with names is that they aren't unique. So you can't get a bl= ack/white answer to a question of "is this call coming from this guy". Als= o true, but somewhat less so, for enterprise names. There, we have better = notions of what acceptable variations are, but we're subject to some of the= shenanigans of the UTF-8 variety.=20 Of course not. But that has nothing to do with a "score" given to others. = If you're claiming a name of "Brian Rosen", the fact that there are other = Brian Rosen's doesn't make your name more or less valid; nor should it affe= ct what a verification service tells others about your name's validity. It= might cause the verification service to find more authentication factors t= o believe you, but that's the verification service's job. At the end of th= e day, the whole point of a verification service is to verify things. Putt= ing the onus on everyone else to decide how valid it is or not, based on sc= ores, misses the whole point of a verification service. Put this in the context of x.509 certificates and Certificate Authorities. = When you connect to "https://fidelity.com", the certificate doesn't say "I= 'm 73% sure this is Fidelity". The closest thing I can think of is Verisig= n's certificate Class model, where the different classes define how "strong= " the assertion is, based on how much validation Verisign performed (among = other things). I am *not* an expert on how their classes truly get used, b= ut as far as I know the point of their classification system is to be used = in different contexts/applications. For example they have one sufficient f= or email, separate from one sufficient for monetary business transactions. > We also can't reliably tie a name to another identity, so we can't attac= h a name to a number with certainty. There's never such a thing as "certainty" obviously, but any assertion abou= t calling name identity must be claimed to be linked to a phone number, bec= ause the calling number is all STIR provides. Having the originator use it= s STIR-based private key to sign a name doesn't make the name itself *valid= *, nor does it mean the name is linked to the phone number. For example, i= f you get a package with just {name=3D"Brian Rosen",versig=3D" 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 186BD11E8199 for ; Thu, 29 Aug 2013 16:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, GB_ABOUTYOU=0.5] 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 TOI7nK2kIwdl for ; Thu, 29 Aug 2013 16:41:43 -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 F340911E80D2 for ; Thu, 29 Aug 2013 16:41:42 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' , Brian Rosen Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAADT0cAAAAyOIAAA4HxgAAA8nIAAAXKhIAAGcErgAAJNRGAAADvA4AAJ/PcgAABIWKAAAHSaIAACSfroA== Date: Thu, 29 Aug 2013 23:41:41 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> 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] [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: Thu, 29 Aug 2013 23:41:47 -0000 I'm not a PKI expert by any stretch, but have had to deal with certs for a = business I run, so from a user perspective, leaving the different applicati= ons (email, web) aside, there seem to be two widely-available versions for = identity (not software signing and other purposes): - standard certs that only prove that the entity owns the domain name or em= ail address; all other information (country, organization name) are user-as= serted and not verified. Issued automatically, only by proving operational = control of the domain. (Temporary possession by the Syrian Electronic Army = excepted.) - EV certs that require a validation by a legal representative; see https:/= /www.cabforum.org/Guidelines_v1_4.pdf The EV cert guidelines make interesting reading. Henning -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Thursday, August 29, 2013 11:12 AM To: Brian Rosen Cc: cnit@ietf.org; Alex Bobotek; Paul Kyzivat Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) On Aug 29, 2013, at 10:19 AM, Brian Rosen wrote: > The problem with names is that they aren't unique. So you can't get a bl= ack/white answer to a question of "is this call coming from this guy". Als= o true, but somewhat less so, for enterprise names. There, we have better = notions of what acceptable variations are, but we're subject to some of the= shenanigans of the UTF-8 variety.=20 Of course not. But that has nothing to do with a "score" given to others. = If you're claiming a name of "Brian Rosen", the fact that there are other = Brian Rosen's doesn't make your name more or less valid; nor should it affe= ct what a verification service tells others about your name's validity. It= might cause the verification service to find more authentication factors t= o believe you, but that's the verification service's job. At the end of th= e day, the whole point of a verification service is to verify things. Putt= ing the onus on everyone else to decide how valid it is or not, based on sc= ores, misses the whole point of a verification service. Put this in the context of x.509 certificates and Certificate Authorities. = When you connect to "https://fidelity.com", the certificate doesn't say "I= 'm 73% sure this is Fidelity". The closest thing I can think of is Verisig= n's certificate Class model, where the different classes define how "strong= " the assertion is, based on how much validation Verisign performed (among = other things). I am *not* an expert on how their classes truly get used, b= ut as far as I know the point of their classification system is to be used = in different contexts/applications. For example they have one sufficient f= or email, separate from one sufficient for monetary business transactions. From kent@bbn.com Fri Aug 30 03:55: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 2307021F994A for ; Fri, 30 Aug 2013 03:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 O0N2Hhkyp8jA for ; Fri, 30 Aug 2013 03:55:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 664ED21F997B for ; Fri, 30 Aug 2013 03:55:40 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:42310 helo=[IPv6:::1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VFMMa-000NRQ-PP; Fri, 30 Aug 2013 06:55:37 -0400 Message-ID: <52207A27.5010105@bbn.com> Date: Fri, 30 Aug 2013 06:55:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Henning Schulzrinne References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "cnit@ietf.org" 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: Fri, 30 Aug 2013 10:55:47 -0000 Henning, What you cite as "standard certs" may be replaced by DANE, using self-signed certs, and avoiding the pitfalls of the current browser PKI model. EV certs attest to the potential trustworthiness of the cert holder, rather than just the name binding. But, the EV cert auditing is pro forma, not very rigorous, despite what one may read. The reason DANE is a great successor to "standard certs" is because it follows the model IO noted earlier, i.e., enabling an entity that is authoritative for a namespace to act as a CA. I am still quite skeptical that any "scoring" system will be intelligible to users. I also have come to question the motives of some of the most vocal proponents of such systems, wondering if their employers may be financial beneficiaries of this technical approach. Steve From br@brianrosen.net Fri Aug 30 07:24: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 1474821F9FB0 for ; Fri, 30 Aug 2013 07:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 chY2Ba1HYPDL for ; Fri, 30 Aug 2013 07:24:10 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 97B1011E81A3 for ; Fri, 30 Aug 2013 07:24:09 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id o20so2339653oag.5 for ; Fri, 30 Aug 2013 07:24: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=CMRZzHs1Su+/8V/qi2YGSEvE2jdtf4r6UQxaaAfqcNU=; b=hRkRFyAa73ubAdErJk4Fitojsi0K2TQ5ZBp03WAAeNlrPDVYAWMA7BFVfBVF+CR5ui AV9wagvcGEAup0nd+9/WKt3uxnWvDyhhIW7hvKDQI40kB65p6I7xWmMyGwGYFofRXohx ArfV/ZGDzTcI+EUuI+LEoeFattyIMKi+buWTpFfcnJPH6rzQdMhWXpyxENWXW6NM4Ju+ jiTTAJH9CIkNAn1+kNmk0YMJM39w4iFUUzVt8Wro2iKQE2eOuuRE2Orfum1OGMDJhsk5 d6lcaGqZJch23O/sfzsNAIUWWSYUMmnQPCo0DPHFX3Xjf//YsmR3Cx8g+xSbOoeKybfP PN6A== X-Gm-Message-State: ALoCoQmz/n7lvonWQkZ9hks59pL3tz7SjGrK6xBWMJGjtoyQDrID8D83PLnS93VByA6mmahsaBdl X-Received: by 10.60.43.131 with SMTP id w3mr7105530oel.10.1377872649047; Fri, 30 Aug 2013 07:24:09 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id xr8sm37258990obc.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 07:24:07 -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: <52207A27.5010105@bbn.com> Date: Fri, 30 Aug 2013 10:24:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E552CE9-DE70-4B45-B230-EC9E68DDCDDE@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> To: Stephen Kent X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Henning Schulzrinne 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: Fri, 30 Aug 2013 14:24:16 -0000 > I also have come to question the motives of some of the most vocal = proponents of such > systems, wondering if their employers may be financial beneficiaries = of this > technical approach. I assume that is directed at me. While true that my employer has such capability and would stand to make = money on the idea, that problem exists, in spades, with the entire stir = effort. Nevertheless, I would not be pushing the idea if I did not = personally think this will be of great value to the caller. You have no = basis to question my sincerity. =20 I submit that it is exceedingly hard for any entity to provide a name = with certainty anywhere near the level of certainty we generally assume = when we state values. We will be able to state with some large degree = of certainty that the phone number is correct. We will have MUCH less = certainty of the name, and wide variation of certainty, no matter what = we do. To assume, or say otherwise is foolish. When you have varying levels of certainty, it helps, a lot, to have an = idea of HOW certain you are. I will give you an example in another = domain. When we report your location as latitude/longitude based on = some measurement, there is both uncertainty (we know you are within some = area, say a radius around a point) and confidence (what is the = probability you are in that circle), which we have ways of expressing. = In location, unlike names, we have ways of measuring confidence and = uncertainty. Having two variables (confidence and uncertainty) does better represent = reality, but makes it exceedingly difficult to compare values. They are = related, but the relationship is complex and you have to know a lot = about the measuring system and the data to, for example, take = uncertainty at 60% confidence and determine the uncertainty at 90% = confidence. Comparing uncertainty at different confidence levels is = exceedingly difficult. In names, we probably have both uncertainty and confidence. Henning = used the example of scoring confidence by source of data. I used = correlation of records to show how one might determine uncertainty. The = state of the art in validating names doesn't really assign separate = confidence and uncertainty. They tend to be mushed into a single score. = Maybe it should be separate, but it isn't. You may be aware of this thing called "Big Data Analytics". There is = science behind scoring data like what I'm advocating, but we're still = pretty much at the beginning of understanding it. What is not so hard, is using it. Lots and lots of companies and = researchers are successfully using the data, for applications not so = dissimilar from what we're discussing. The situation we have now is that we have service providers who will = assert names that have no validation. It's what the subscriber says it = is. Some service providers are better than others, but there are many = service providers, and no way to compare them. The only way around that = today is to use the termination side query that exists, but the = uncertainty is medium with only the phone number as input. Confidence = is all over the map, depending on how much data we have on the phone = number and the name. We currently threshold the data, and that = threshold is not controllable by the user. Not a great situation, but = it works within the limits of the current caller-id paradigm. No other = uses of the database I'm aware of is that simplistic. We know too much = about the data to be that simplistic. We can do what Henning proposed - send multiple names with who asserts = them and what it represents. Labeling is helpful. What the labeling = does is allow the termination to come up with it's own notion of = confidence. I'm not worried about sorting out that information at the = termination end. However. to ignore score is to ignore reality. We = have, compared to number, low to medium confidence if you want = reasonably high certainty that the name is right. =20 Sending a score is cheap. Make it optional if you wish. Brian From timothy.dwight@verizon.com Fri Aug 30 07:56:23 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 1AA1521E80D6 for ; Fri, 30 Aug 2013 07:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=0.674, 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 243FClcPfev7 for ; Fri, 30 Aug 2013 07:56:05 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD7321F9C29 for ; Fri, 30 Aug 2013 07:55:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe02.verizonbusiness.com with ESMTP; 30 Aug 2013 14:55:36 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,991,1367971200"; d="scan'208";a="547423127" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi01.verizon.com with ESMTP; 30 Aug 2013 14:55:35 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Fri, 30 Aug 2013 10:55:35 -0400 To: Brian Rosen , Stephen Kent Date: Fri, 30 Aug 2013 10:55:34 -0400 Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6ljRM1eGWH3KCQSP290saaOnmgQAAAY/cA Message-ID: <2B0F677F0B95454297753F58D4A07FA3012B1526AD@FHDP1LUMXC7V31.us.one.verizon.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> In-Reply-To: <0E552CE9-DE70-4B45-B230-EC9E68DDCDDE@brianrosen.net> 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 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: Fri, 30 Aug 2013 14:56:26 -0000 Brian, You said: "We can do what Henning proposed - send multiple names with who asserts the= m and what it represents. " Isn't this problematic in the "benign spoofing" scenario? Suppose the doct= or-on-the-golf-course example. He places a call to a patient using his cel= l phone, but wants the called party's caller ID to display the name of his = practice. But then this call arrives at the terminating user or SP, who se= es a greater certainty associated with his real name than with the name of = his practice. How would we prevent the terminating side from over-riding w= hat he's intended (and we've intended to allow him) to do? tim From Henning.Schulzrinne@fcc.gov Fri Aug 30 08:05:54 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 7387A21F9E3B for ; Fri, 30 Aug 2013 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 viLtlu8zOjLw for ; Fri, 30 Aug 2013 08:05:49 -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 28D9921F9E3A for ; Fri, 30 Aug 2013 08:05:47 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'Dwight, Timothy M (Tim)'" , Brian Rosen , Stephen Kent Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAADT0cAAAAyOIAAA4HxgAAA8nIAAAXKhIAAGcErgAAJNRGAAADvA4AAJ/PcgAABIWKAAAHSaIAACSfroAAgMUWAAAdH/AAAARmiAAAIVX+w Date: Fri, 30 Aug 2013 15:05:45 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012B1526AD@FHDP1LUMXC7V31.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] [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: Fri, 30 Aug 2013 15:05:54 -0000 I suspect you would need a "portable" mechanism, which then starts to look = awfully similar to certs where a CA-like entity (say, the home carrier in o= ur case) provides their customer with credentials that the customer can use= outside that relationship. By analogy, this isn't altogether different fro= m the model of various identity-like cards, from a library card to a studen= t ID, that are used outside their original context, but it raises all the u= sual CA-like concerns. Some of these are mitigated if, DANE-like, the recei= ving entity can validate that Verizon is indeed the carrier for a certain p= hone number, so that trusting a Verizon-issued credential is reasonable. Th= us, you get a trust chain (among several possible): Caller proves assignment of phone number --> phone number is mapped reliabl= y to carrier --> carrier asserts limited attributes of customer We more-or-less have the middle step in place today and STIR provides the f= irst step. Longer term, I wonder if the mediated call signaling model will become more= common, i.e., where the doctor's phone routes calls through an outbound pr= oxy in the office. That reduces the number of cases where you need such por= table credentials. -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Friday, August 30, 2013 10:56 AM To: Brian Rosen; Stephen Kent Cc: cnit@ietf.org; Henning Schulzrinne Subject: RE: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) Brian, You said: "We can do what Henning proposed - send multiple names with who asserts the= m and what it represents. " Isn't this problematic in the "benign spoofing" scenario? Suppose the doct= or-on-the-golf-course example. He places a call to a patient using his cel= l phone, but wants the called party's caller ID to display the name of his = practice. But then this call arrives at the terminating user or SP, who se= es a greater certainty associated with his real name than with the name of = his practice. How would we prevent the terminating side from over-riding w= hat he's intended (and we've intended to allow him) to do? tim From dcrocker@bbiw.net Fri Aug 30 07:53: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 C0D5311E81AB for ; Fri, 30 Aug 2013 07:53:47 -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 49SWFRJ7JZ66 for ; Fri, 30 Aug 2013 07:53:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 06EE811E81A9 for ; Fri, 30 Aug 2013 07:53:39 -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 r7UErSxl001768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Aug 2013 07:53:31 -0700 Message-ID: <5220B1E1.6050508@bbiw.net> Date: Fri, 30 Aug 2013 07:53:21 -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: Stephen Kent References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> In-Reply-To: <52207A27.5010105@bbn.com> 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.67]); Fri, 30 Aug 2013 07:53:32 -0700 (PDT) X-Mailman-Approved-At: Fri, 30 Aug 2013 09:01:11 -0700 Cc: "cnit@ietf.org" , Henning Schulzrinne 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: Fri, 30 Aug 2013 14:53:48 -0000 On 8/30/2013 3:55 AM, Stephen Kent wrote: > I am still quite skeptical that any "scoring" system will be > intelligible to users. No need for skepticism. Skepticism is based on doubt and this is simpler than that. It won't be intelligible; and to the extent it is, it won't affect their behavior very much. This isn't a new topic, except in this venue. > I also have come to question the motives of some of the most vocal > proponents of such systems, wondering if their employers may be > financial beneficiaries of this technical approach. Most people in IETF discussions have some sort of bias. By itself, that's not typically very interesting, unless a person has undue influence on the decision-making and no counter-balance in the process. So on the average, our protection against the biases is diverse participation, with serious, frank, open and constructive exploration and debate. Focusing on the substance makes personal bias mostly irrelevant. For me, one of the serious flags gets raised when an assertion is inappropriately simplistic, especially when accompanied by attempts to terminate that frank and open discussion that would explore the assertion. In the current discussion, there is a tendency to assume that the topic is relatively straightforward in terms of engineering, deployment and outcome (effects). I am not aware of any basis for such confidence, but am aware of quite a bit of field experience to the contrary. The group really should seek to formulate some very clear, non-technical statements about what it trying to produce and the basis for believing that it will be useful. So far, quite a bit is getting buried in verbal handwaves that approximate the cliche'd "and then a miracle happens". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Fri Aug 30 09:29:03 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 D6ADF21F9D95 for ; Fri, 30 Aug 2013 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.94 X-Spam-Level: X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_74=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 A+txcFbi7sSe for ; Fri, 30 Aug 2013 09:28:58 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6889C21F9D12 for ; Fri, 30 Aug 2013 09:28:58 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7UGSpq1015230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Aug 2013 16:28:52 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 r7UGSnVN003646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 16:28:50 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UGSnJo028206; Fri, 30 Aug 2013 16:28:49 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Aug 2013 09:28:49 -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: <0E552CE9-DE70-4B45-B230-EC9E68DDCDDE@brianrosen.net> Date: Fri, 30 Aug 2013 12:28:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <56B55B95-F402-41BD-A19F-DD67933A525C@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "cnit@ietf.org" , Stephen Kent , Henning Schulzrinne 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: Fri, 30 Aug 2013 16:29:04 -0000 I think I'm repeating myself, but maybe if I say it differently it will = be clearer... The challenge with sending a score is that the receiver (a) can't = believe it, and (b) doesn't know what it truly means relative to the = receiver's notion of score values. =20 Afaik, today email spam systems do have notions of score, but it's = something the receivers create themselves - it's under the control and = policy decision of the receiver. For example, when BigCorp receives an = email from someone, then they run a bunch of checks against the email = headers+body resulting in a final score and determine based on that = whether to put the message in a spam folder or not. (I'm simplifying) = But that's something BigCorp can control, knowing how the score is = calculated and trusting their own spam-filter systems/code. I don't debate for a second that TARGUSinfo databases have this type of = information. But when you're queried by the terminating carrier, you = could actually give them that scoring information, today. That would = make sense because they have a relationship with you - they're paying = you for the data, so they trust you, and since they have a direct = relationship with you they can know what the score actually means and = thus how to determine their local thresholds and policies. If you'd = like to define a way for that to work, that makes some sense to me - = it's what draft-wing-sipping-spam-score was trying to do. But instead = what you're talking about is different. What you're proposing for CNIT is a reputation-based naming authority. = It's really the same as web-pki style CAs, but much weaker. Let's = assume the CA model worked perfectly. I've been told there are ~160 = trusted CAs. Do you think CNIT will end up with around the same, on a = world-wide basis? If so, is it likely that every receiving carrier of = the ~10,000 SIP providers world-wide would understand and trust the = properties of a 0-100 score from ~160 different CAs they have no direct = relationship with? Even if we focus just on the USA, there're ~1500 = providers and about a dozen sources of this type of data today. There is something like this in the email world, fwiw: RFC 5518 = vouch-by-reference. I don't know if it's used or not in the real world, = but its assertion is a lot simpler and more constrained. -hadriel On Aug 30, 2013, at 10:24 AM, Brian Rosen wrote: >> I also have come to question the motives of some of the most vocal = proponents of such >> systems, wondering if their employers may be financial beneficiaries = of this >> technical approach. > I assume that is directed at me. >=20 > While true that my employer has such capability and would stand to = make money on the idea, that problem exists, in spades, with the entire = stir effort. Nevertheless, I would not be pushing the idea if I did not = personally think this will be of great value to the caller. You have no = basis to question my sincerity. =20 >=20 > I submit that it is exceedingly hard for any entity to provide a name = with certainty anywhere near the level of certainty we generally assume = when we state values. We will be able to state with some large degree = of certainty that the phone number is correct. We will have MUCH less = certainty of the name, and wide variation of certainty, no matter what = we do. To assume, or say otherwise is foolish. >=20 > When you have varying levels of certainty, it helps, a lot, to have an = idea of HOW certain you are. I will give you an example in another = domain. When we report your location as latitude/longitude based on = some measurement, there is both uncertainty (we know you are within some = area, say a radius around a point) and confidence (what is the = probability you are in that circle), which we have ways of expressing. = In location, unlike names, we have ways of measuring confidence and = uncertainty. >=20 > Having two variables (confidence and uncertainty) does better = represent reality, but makes it exceedingly difficult to compare values. = They are related, but the relationship is complex and you have to know = a lot about the measuring system and the data to, for example, take = uncertainty at 60% confidence and determine the uncertainty at 90% = confidence. Comparing uncertainty at different confidence levels is = exceedingly difficult. >=20 > In names, we probably have both uncertainty and confidence. Henning = used the example of scoring confidence by source of data. I used = correlation of records to show how one might determine uncertainty. The = state of the art in validating names doesn't really assign separate = confidence and uncertainty. They tend to be mushed into a single score. = Maybe it should be separate, but it isn't. >=20 > You may be aware of this thing called "Big Data Analytics". There is = science behind scoring data like what I'm advocating, but we're still = pretty much at the beginning of understanding it. >=20 > What is not so hard, is using it. Lots and lots of companies and = researchers are successfully using the data, for applications not so = dissimilar from what we're discussing. >=20 > The situation we have now is that we have service providers who will = assert names that have no validation. It's what the subscriber says it = is. Some service providers are better than others, but there are many = service providers, and no way to compare them. The only way around that = today is to use the termination side query that exists, but the = uncertainty is medium with only the phone number as input. Confidence = is all over the map, depending on how much data we have on the phone = number and the name. We currently threshold the data, and that = threshold is not controllable by the user. Not a great situation, but = it works within the limits of the current caller-id paradigm. No other = uses of the database I'm aware of is that simplistic. We know too much = about the data to be that simplistic. >=20 > We can do what Henning proposed - send multiple names with who asserts = them and what it represents. Labeling is helpful. What the labeling = does is allow the termination to come up with it's own notion of = confidence. I'm not worried about sorting out that information at the = termination end. However. to ignore score is to ignore reality. We = have, compared to number, low to medium confidence if you want = reasonably high certainty that the name is right. =20 >=20 > Sending a score is cheap. Make it optional if you wish. >=20 > Brian >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From hadriel.kaplan@oracle.com Fri Aug 30 09:44:52 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 96D6C21E80EF for ; Fri, 30 Aug 2013 09:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_75=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 nTXIr-D-8ZlP for ; Fri, 30 Aug 2013 09:44:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1476621E80A5 for ; Fri, 30 Aug 2013 09:44:46 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7UGid0q025169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Aug 2013 16:44:40 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UGic30013476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 16:44:39 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UGic8n013467; Fri, 30 Aug 2013 16:44:38 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Aug 2013 09:44:38 -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: Fri, 30 Aug 2013 12:44:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9D3DF6A2-F2F0-4766-B9B3-EBCBAB3C4299@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: cnit@ietf.org, Stephen Kent , "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: Fri, 30 Aug 2013 16:44:52 -0000 On Aug 30, 2013, at 11:05 AM, Henning Schulzrinne = wrote: > I suspect you would need a "portable" mechanism, which then starts to = look awfully similar to certs where a CA-like entity (say, the home = carrier in our case) provides their customer with credentials that the = customer can use outside that relationship. By analogy, this isn't = altogether different from the model of various identity-like cards, from = a library card to a student ID, that are used outside their original = context, but it raises all the usual CA-like concerns. Some of these are = mitigated if, DANE-like, the receiving entity can validate that Verizon = is indeed the carrier for a certain phone number, so that trusting a = Verizon-issued credential is reasonable. Thus, you get a trust chain = (among several possible): > Caller proves assignment of phone number --> phone number is mapped = reliably to carrier --> carrier asserts limited attributes of customer I think the problem with this is that we know we can't trust the = "carriers". That's how we got to STIR to begin with. I totally trust = Verizon, and a bunch of big carriers for that matter, but there are lots = of SIP service "providers", of various sizes and shades of pink. For = example we know for a fact that some "providers" are complicit in = generating fake calling numbers *and* names - it's part of their = business model. If we could decide which ones were bad purely on statistical reputation = alone, and stop displaying their numbers+names, then the STIR solution = would be quite different... maybe even unnecessary. We know we can't do = that for political, legal, and operational/scalability reasons. That's = why we think doing STIR the way we've been talking about it is = worth-while, presumably. No? > Longer term, I wonder if the mediated call signaling model will become = more common, i.e., where the doctor's phone routes calls through an = outbound proxy in the office. That reduces the number of cases where you = need such portable credentials. Some of that happens already today, fwiw. I do expect it to become more = common if STIR gets deployed, if it's non-trivial to authorize = third-party source identity use. -hadriel From br@brianrosen.net Fri Aug 30 10:07:27 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 62BB621F9FBA for ; Fri, 30 Aug 2013 10:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_74=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 AICo-QaVcFeu for ; Fri, 30 Aug 2013 10:07:21 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9B1521F88B4 for ; Fri, 30 Aug 2013 10:07:12 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so1113642qeb.17 for ; Fri, 30 Aug 2013 10:07: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=pbDLaHFVQp55Gh7tm5rqH1uLqCfnRKGEqVqvvsjwLvY=; b=ibVie7Z1gCf7aUB3GjY90YYX8oMX26pIxrzsZwc5GTc7aJ2JprAyhwGxq2p1VpvWWA nblJzvUx/7HTCYjgSSIDf/VQNKVeHg3jEkPAH/blEt3asSa5AgnI4QNivHK4ZT4wJ1su OAuWchYfIqXDH3V+txSKp4LuUReuktrhPEHFJShL0ZwCvKXQb1zIVciKNL4Q3H8CAwnF 5jt9qnNk3ixb/5TMx8dG5wZiq/kT6Hl6/y2UhyGb1BufX3Ikfcq7Qkp8bpprPQiwFMI9 Vk1Pf+SigGAU6ndo542G5V+5F9PfUBkyLZ8K1LDO24eAWqfHdZIziKGwyo2ZfWQwzs3r 5FoA== X-Gm-Message-State: ALoCoQmecRBsCCvFQI4eFJQ9PTqtAT9p1p7VvIcK796i/EixuTv+99aVExb4yg2Z74aWaUSyuShU X-Received: by 10.224.131.197 with SMTP id y5mr13671280qas.23.1377882428845; Fri, 30 Aug 2013 10:07:08 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id i10sm51308976qev.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 10:07:07 -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: <56B55B95-F402-41BD-A19F-DD67933A525C@oracle.com> Date: Fri, 30 Aug 2013 13:07:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0CD4C29A-464D-41C0-A57A-E203CB2BD5F4@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <56B55B95-F402-41BD-A19F-DD67933A525C@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Stephen Kent , Henning Schulzrinne 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: Fri, 30 Aug 2013 17:07:27 -0000 While I understand the problem you are pointing out, I don't think it's = anywhere near as bad as you are projecting it. I think in any country, = there are only a small number of suitable validation services. I think = that for any given recipient, knowing the in-country validators is good = enough, or at most the few neighbor country's validators. I think that = the most likely entities to actually deal with the value are folks like = Apple and Google, or Samsung and Nokia who create with the received call = UIs, and they could develop methods rate a few thousand validators. I = expect we will see meta-rating services that deal with the problem also. = If the score is a scaler, then it's possible to derate a score if you = have a rating on the scoring service. Mostly I would say that having the score is infinitely better than not = having the score, even with the problem that state of the art today = doesn't let us have a more definitive mechanism. Brian On Aug 30, 2013, at 12:28 PM, Hadriel Kaplan = wrote: >=20 > I think I'm repeating myself, but maybe if I say it differently it = will be clearer... >=20 > The challenge with sending a score is that the receiver (a) can't = believe it, and (b) doesn't know what it truly means relative to the = receiver's notion of score values. =20 >=20 > Afaik, today email spam systems do have notions of score, but it's = something the receivers create themselves - it's under the control and = policy decision of the receiver. For example, when BigCorp receives an = email from someone, then they run a bunch of checks against the email = headers+body resulting in a final score and determine based on that = whether to put the message in a spam folder or not. (I'm simplifying) = But that's something BigCorp can control, knowing how the score is = calculated and trusting their own spam-filter systems/code. >=20 > I don't debate for a second that TARGUSinfo databases have this type = of information. But when you're queried by the terminating carrier, you = could actually give them that scoring information, today. That would = make sense because they have a relationship with you - they're paying = you for the data, so they trust you, and since they have a direct = relationship with you they can know what the score actually means and = thus how to determine their local thresholds and policies. If you'd = like to define a way for that to work, that makes some sense to me - = it's what draft-wing-sipping-spam-score was trying to do. But instead = what you're talking about is different. >=20 > What you're proposing for CNIT is a reputation-based naming authority. = It's really the same as web-pki style CAs, but much weaker. Let's = assume the CA model worked perfectly. I've been told there are ~160 = trusted CAs. Do you think CNIT will end up with around the same, on a = world-wide basis? If so, is it likely that every receiving carrier of = the ~10,000 SIP providers world-wide would understand and trust the = properties of a 0-100 score from ~160 different CAs they have no direct = relationship with? Even if we focus just on the USA, there're ~1500 = providers and about a dozen sources of this type of data today. >=20 > There is something like this in the email world, fwiw: RFC 5518 = vouch-by-reference. I don't know if it's used or not in the real world, = but its assertion is a lot simpler and more constrained. >=20 > -hadriel >=20 >=20 > On Aug 30, 2013, at 10:24 AM, Brian Rosen wrote: >=20 >>> I also have come to question the motives of some of the most vocal = proponents of such >>> systems, wondering if their employers may be financial beneficiaries = of this >>> technical approach. >> I assume that is directed at me. >>=20 >> While true that my employer has such capability and would stand to = make money on the idea, that problem exists, in spades, with the entire = stir effort. Nevertheless, I would not be pushing the idea if I did not = personally think this will be of great value to the caller. You have no = basis to question my sincerity. =20 >>=20 >> I submit that it is exceedingly hard for any entity to provide a name = with certainty anywhere near the level of certainty we generally assume = when we state values. We will be able to state with some large degree = of certainty that the phone number is correct. We will have MUCH less = certainty of the name, and wide variation of certainty, no matter what = we do. To assume, or say otherwise is foolish. >>=20 >> When you have varying levels of certainty, it helps, a lot, to have = an idea of HOW certain you are. I will give you an example in another = domain. When we report your location as latitude/longitude based on = some measurement, there is both uncertainty (we know you are within some = area, say a radius around a point) and confidence (what is the = probability you are in that circle), which we have ways of expressing. = In location, unlike names, we have ways of measuring confidence and = uncertainty. >>=20 >> Having two variables (confidence and uncertainty) does better = represent reality, but makes it exceedingly difficult to compare values. = They are related, but the relationship is complex and you have to know = a lot about the measuring system and the data to, for example, take = uncertainty at 60% confidence and determine the uncertainty at 90% = confidence. Comparing uncertainty at different confidence levels is = exceedingly difficult. >>=20 >> In names, we probably have both uncertainty and confidence. Henning = used the example of scoring confidence by source of data. I used = correlation of records to show how one might determine uncertainty. The = state of the art in validating names doesn't really assign separate = confidence and uncertainty. They tend to be mushed into a single score. = Maybe it should be separate, but it isn't. >>=20 >> You may be aware of this thing called "Big Data Analytics". There is = science behind scoring data like what I'm advocating, but we're still = pretty much at the beginning of understanding it. >>=20 >> What is not so hard, is using it. Lots and lots of companies and = researchers are successfully using the data, for applications not so = dissimilar from what we're discussing. >>=20 >> The situation we have now is that we have service providers who will = assert names that have no validation. It's what the subscriber says it = is. Some service providers are better than others, but there are many = service providers, and no way to compare them. The only way around that = today is to use the termination side query that exists, but the = uncertainty is medium with only the phone number as input. Confidence = is all over the map, depending on how much data we have on the phone = number and the name. We currently threshold the data, and that = threshold is not controllable by the user. Not a great situation, but = it works within the limits of the current caller-id paradigm. No other = uses of the database I'm aware of is that simplistic. We know too much = about the data to be that simplistic. >>=20 >> We can do what Henning proposed - send multiple names with who = asserts them and what it represents. Labeling is helpful. What the = labeling does is allow the termination to come up with it's own notion = of confidence. I'm not worried about sorting out that information at = the termination end. However. to ignore score is to ignore reality. We = have, compared to number, low to medium confidence if you want = reasonably high certainty that the name is right. =20 >>=20 >> Sending a score is cheap. Make it optional if you wish. >>=20 >> Brian >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 From dhc@dcrocker.net Fri Aug 30 10:13: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 0ADD021F81FF for ; Fri, 30 Aug 2013 10:13:53 -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 Q-CZWIfgOMF6 for ; Fri, 30 Aug 2013 10:13:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 77ECC11E80FA for ; Fri, 30 Aug 2013 10:13:37 -0700 (PDT) Received: from [172.29.107.180] (wsip-184-191-162-57.sd.sd.cox.net [184.191.162.57]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7UHDQCh004919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Aug 2013 10:13:30 -0700 Message-ID: <5220D2B0.3000601@dcrocker.net> Date: Fri, 30 Aug 2013 10:13:20 -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: Hadriel Kaplan References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <56B55B95-F402-41BD-A19F-DD67933A525C@oracle.com> In-Reply-To: <56B55B95-F402-41BD-A19F-DD67933A525C@oracle.com> 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]); Fri, 30 Aug 2013 10:13:30 -0700 (PDT) Cc: "cnit@ietf.org" , 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 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: Fri, 30 Aug 2013 17:13:53 -0000 On 8/30/2013 9:28 AM, Hadriel Kaplan wrote: > > I think I'm repeating myself, but maybe if I say it differently it > will be clearer... > > The challenge with sending a score is that the receiver (a) can't > believe it, and (b) doesn't know what it truly means relative to the > receiver's notion of score values. +1 > Afaik, today email spam systems do have notions of score, but it's > something the receivers create themselves - it's under the control > and policy decision of the receiver. Receivers have very complex filtering engines, typically with /layers/ of many different scores, based on a variety of attributes, and factored into highly contingent analysis engines. Users never see any of this; the engines feed into basic handling choices, such as inbox vs. spam folder. Over the last 15 years, there have been a number of startup company efforts to "empower' end-users with quality assessment information. Essentially all have failed. The only report I've heard of real efficacy was at Yahoo, where they boiled it down to a trust/don't-trust/don't-know distinction, but this certainly has not gained traction in the industry. References to thinks like EV certs could benefit from some reporting on efficacy; my impression is that they've had no effect on end-users, any more than the lock symbol at the bottom of the web page. > What you're proposing for CNIT is a reputation-based naming An essential point from many years of email reputation -- and by the way way, physical world reputation -- is the need for multiple and potentially competing services. > There is something like this in the email world, fwiw: RFC 5518 > vouch-by-reference. I don't know if it's used or not in the real > world, but its assertion is a lot simpler and more constrained. VBR isn't used. Reasonable idea, but no market traction. And then there's the more recent Repute working group that is just finishing up: http://datatracker.ietf.org/wg/repute/ On the average, folks tend to approach abuse remediation with an assumption that it is tractable to assertion of a bit more control and that that isn't difficult. On the average, that hasn't produced encouraging results. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From br@brianrosen.net Fri Aug 30 10:22:07 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 ED44421E80DD for ; Fri, 30 Aug 2013 10:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, J_CHICKENPOX_75=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 gOqn8IRW3vFL for ; Fri, 30 Aug 2013 10:21:59 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 33B7421F9C7A for ; Fri, 30 Aug 2013 10:21:59 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id bv4so1315280qab.10 for ; Fri, 30 Aug 2013 10:21:54 -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=xOBwYbeQ155dlbwqgZ6o7O6d/RWTBHQCL/SA03ixPn8=; b=D1pd3CkP/AN1lqstBjIEVa2MXHZst2c/HBy6ONVgRbCD4FcZATxBHTqgQEv7H6fERl faNB5vOl2bawR3Q5XB0nAjRI+N1HD92ndSQsqXPNsslYXmBoMEoT6eek7OE+Lbj5F/Vo uaRmhpAe/kKhx6zbh6A4O/SnPdzCa+av9OrXZDAoJ2Vi7Nn8ijwTpPSrWlHZxFoxT77k HOMtrn5yiYDUTpjOFtC7XB1agYoK83DdtAe4ZQKkmC7uDfGlRv8QqrKaHhPaT/lmBNpZ cXtlfr7DPhYCUPKWoK5dx+f/5O3QaPXZa+t93dajDd7aW/Z4UoA24wG+zrNEeBvmfrdI U2Rw== X-Gm-Message-State: ALoCoQnm5OkcLpIK8A23FvIPhIjbbH9oj6ITZ5VwX8hQXydI9/0pTwOWHAeH6ZXK6SrjR+SiC/qp X-Received: by 10.49.71.41 with SMTP id r9mr12686988qeu.49.1377883314064; Fri, 30 Aug 2013 10:21:54 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 2sm51374688qen.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 10:21: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: <9D3DF6A2-F2F0-4766-B9B3-EBCBAB3C4299@oracle.com> Date: Fri, 30 Aug 2013 13:21:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org, Stephen Kent , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne 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: Fri, 30 Aug 2013 17:22:07 -0000 Hadriel You seem to be rejecting all ideas. If you don't like scoring and you don't like multiple names with source, = what do you like? ?Magic happens here? I don't think it's going to be hard to authorize third party use. We seem to agree that within a country, there needs to be one database = of credentials. Since there are many entities that delegate numbers, = that database needs a protocol or API to enable delegation from all = those entities. It will be able to track delegations, so that if the = national number authority delegates a number to Carrier A and Carrier A = delegates it to SP B and SP B delegates it to enterprise C, then the = authority, A and B will use that protocol or API to tell the database. = The database will then know to allow enterprise C to permit enterprise D = to assert the number on its behalf, and can do so with the same protocol = or API. The credential used to enable the protocol or API to do the = delegation could be the same credential used to sign, although the = database probably needs to assign an identity to A, B, C and D to allow = a new delegation to occur. That identity (it's like a SPID, but needs = to allow enterprises, doctors and others to get IDs) is associated with = the delegations. The database might only expose the credentials for a = given number, but it tracks the actual delegations inside as identity 1 = delegated TN range X to Identity 2 at such and such a time. Delegations = have to be revocable, of course (cessation of service or return of = numbers to inventory). Brian On Aug 30, 2013, at 12:44 PM, Hadriel Kaplan = wrote: >=20 > On Aug 30, 2013, at 11:05 AM, Henning Schulzrinne = wrote: >=20 >> I suspect you would need a "portable" mechanism, which then starts to = look awfully similar to certs where a CA-like entity (say, the home = carrier in our case) provides their customer with credentials that the = customer can use outside that relationship. By analogy, this isn't = altogether different from the model of various identity-like cards, from = a library card to a student ID, that are used outside their original = context, but it raises all the usual CA-like concerns. Some of these are = mitigated if, DANE-like, the receiving entity can validate that Verizon = is indeed the carrier for a certain phone number, so that trusting a = Verizon-issued credential is reasonable. Thus, you get a trust chain = (among several possible): >> Caller proves assignment of phone number --> phone number is mapped = reliably to carrier --> carrier asserts limited attributes of customer >=20 > I think the problem with this is that we know we can't trust the = "carriers". That's how we got to STIR to begin with. I totally trust = Verizon, and a bunch of big carriers for that matter, but there are lots = of SIP service "providers", of various sizes and shades of pink. For = example we know for a fact that some "providers" are complicit in = generating fake calling numbers *and* names - it's part of their = business model. >=20 > If we could decide which ones were bad purely on statistical = reputation alone, and stop displaying their numbers+names, then the STIR = solution would be quite different... maybe even unnecessary. We know we = can't do that for political, legal, and operational/scalability reasons. = That's why we think doing STIR the way we've been talking about it is = worth-while, presumably. No? >=20 >=20 >> Longer term, I wonder if the mediated call signaling model will = become more common, i.e., where the doctor's phone routes calls through = an outbound proxy in the office. That reduces the number of cases where = you need such portable credentials. >=20 > Some of that happens already today, fwiw. I do expect it to become = more common if STIR gets deployed, if it's non-trivial to authorize = third-party source identity use. >=20 > -hadriel >=20 From dhc@dcrocker.net Fri Aug 30 10:27: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 3E51C21F9D99 for ; Fri, 30 Aug 2013 10:27:14 -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 0KhHQ02Ky3-5 for ; Fri, 30 Aug 2013 10:27:09 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 362A421F9D98 for ; Fri, 30 Aug 2013 10:27:09 -0700 (PDT) Received: from [172.29.107.180] (wsip-184-191-162-57.sd.sd.cox.net [184.191.162.57]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7UHQw5m005144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Aug 2013 10:27:01 -0700 Message-ID: <5220D5DB.8050804@dcrocker.net> Date: Fri, 30 Aug 2013 10:26:51 -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: Brian Rosen References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> 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]); Fri, 30 Aug 2013 10:27:04 -0700 (PDT) Cc: cnit@ietf.org, Henning Schulzrinne , Stephen Kent , "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 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: Fri, 30 Aug 2013 17:27:14 -0000 On 8/30/2013 10:21 AM, Brian Rosen wrote: > Hadriel > > You seem to be rejecting all ideas. Whereas you seem to be rejecting all concerns. So, Brian and others who are convinced that this topic is straightforward and easily amenable to effective mechanisms: Please cite your evidence. Look for other areas with a history of abuse that were significantly mitigated by the approach you are espousing. Over the course of my own involvement in anti-abuse, over the last 15 years, I know of none that qualifies. > We seem to agree that within a country, there needs to be one database of credentials. Oh? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From br@brianrosen.net Fri Aug 30 10:40:52 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 2365721F99BF for ; Fri, 30 Aug 2013 10:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.245 X-Spam-Level: X-Spam-Status: No, score=-103.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 574qa2DZ2oKb for ; Fri, 30 Aug 2013 10:40:45 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id B533B21F918C for ; Fri, 30 Aug 2013 10:40:44 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id fb19so2193420obc.10 for ; Fri, 30 Aug 2013 10:40:44 -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=mzs3V6ki1whWc026f7y6sfKoI5XoANLORboJJz4/r2Y=; b=h6tPHQ395zTx14rZBnq8ztfuwIK03KKSdzRJxpSSBGP5wAC6lMl0pSetnG46Mcl3rA yiR9cEm+c7s9CTZYTXRc8ncr6iMJJ49O6cNwkZ0lneMoV1+hcsnoES/GfU3jlRC2k7J9 JTKx8diwzmpF10nUscXIlb7IA50krDD5iXDFLN5WlYmlULp7V8ajdWAPzNjOrkVgMMre thZOrV8U0BmmzmSdI4tQqLi+W7kij5pnlKUiadRQc5/63l/2zIPOkYiWEZ1cys1uhLdy sO0YRNSLF78FY1pz2ms4LlmkyRkPhOgj+wOj95c8ZzSWyDfAfmE7fDLBkpveCD9gGRp6 o2xw== X-Gm-Message-State: ALoCoQmLZ3iSFxslFgmwVVOjErh1iGe83V2CLYB2XGr2SH93o/kfYe7bRdAd1a55WEyKQAsI5TwW X-Received: by 10.60.47.129 with SMTP id d1mr1178163oen.84.1377884444252; Fri, 30 Aug 2013 10:40:44 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id pt4sm38186284obb.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 10:40:43 -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: <5220D5DB.8050804@dcrocker.net> Date: Fri, 30 Aug 2013 13:40:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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 > To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org, Henning Schulzrinne , Stephen Kent , "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: Fri, 30 Aug 2013 17:40:52 -0000 Okay. We support dozens of customers who had serious fraud abuse until = they started using our database to evaluate callers to their call = center. Typically, they query with 3-6 fields. They get a score back. = They decide how to handle the caller based on the score. Responses = range from a polite goodbye to a what can we do to get your business, = and lots in between. The call taker doesn't often see the score = directly - the call branch tree is modified automatically (what to ask, = what to offer, what to accept, how to handle exceptions). I'd have to = get some numbers to cite what the usual decline in fraud is, but we have = lots of long term customers. 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. What I know is, = it's useful, and we'll figure out a way. 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. Dunno, = but I have high confidence (with moderate uncertainty) that folks like = Apple and Google will figure out a good UI to use the data. Brian On Aug 30, 2013, at 1:26 PM, Dave Crocker wrote: > On 8/30/2013 10:21 AM, Brian Rosen wrote: >> Hadriel >>=20 >> You seem to be rejecting all ideas. >=20 > Whereas you seem to be rejecting all concerns. >=20 >=20 > So, Brian and others who are convinced that this topic is = straightforward and easily amenable to effective mechanisms: >=20 > Please cite your evidence. >=20 > Look for other areas with a history of abuse that were = significantly mitigated by the approach you are espousing. >=20 > Over the course of my own involvement in anti-abuse, over the last 15 = years, I know of none that qualifies. >=20 >=20 >=20 >> We seem to agree that within a country, there needs to be one = database of credentials. >=20 > Oh? >=20 >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From dhc@dcrocker.net Fri Aug 30 10:41:31 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 5B5E221F9DDB for ; Fri, 30 Aug 2013 10:41:31 -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 RDzWMJT9c1zB for ; Fri, 30 Aug 2013 10:41:26 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8108321F9A3D for ; Fri, 30 Aug 2013 10:41:24 -0700 (PDT) Received: from [172.29.107.180] (wsip-184-191-162-57.sd.sd.cox.net [184.191.162.57]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7UHfKWs005499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Aug 2013 10:41:23 -0700 Message-ID: <5220D939.7010600@dcrocker.net> Date: Fri, 30 Aug 2013 10:41:13 -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: Brian Rosen References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> In-Reply-To: <0E552CE9-DE70-4B45-B230-EC9E68DDCDDE@brianrosen.net> 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]); Fri, 30 Aug 2013 10:41:24 -0700 (PDT) Cc: "cnit@ietf.org" 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 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: Fri, 30 Aug 2013 17:41:31 -0000 On 8/30/2013 7:24 AM, Brian Rosen wrote: > I submit that it is exceedingly hard for any entity to provide a name > with certainty anywhere near the level of certainty we generally > assume when we state values. That's a foundational point. What is not clear is how that is factored into assumptions about the receive-side evaluation process and why the assumptions are valid. > When you have varying levels of certainty, it helps, a lot, to have > an idea of HOW certain you are. In the abstract, perhaps. In the current discussion, how is 'variable certainty' to be used and by what agent and why is that expectation plausible? For example, one scenario might provide for the callee (human user) to see a name and a certainty factor and assert that the callee will make differential choices accordingly. In practice, the callee is likely to confuse the certainty assertion with a quality/safety assertion. Anything less than 100% will therefore get rejected. But that's just a guess. The reality of designing such human interaction mechanisms is that the right choice is always based on testing, not theory. > You may be aware of this thing called "Big Data Analytics". There is > science behind scoring data like what I'm advocating, but we're still > pretty much at the beginning of understanding it. > > What is not so hard, is using it. To the extent that you mean use by an average end-user, who is making a real-time decision about whether to answer the call or assess who is calling them, you are quite wrong. > Sending a score is cheap. Make it optional if you wish. 1. Cheap is not the same as free. 2. Cheap is not the same as useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Fri Aug 30 11:02:02 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 7A75A21F9D70 for ; Fri, 30 Aug 2013 11:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_BIZOP=0.7] 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 jf23Rq7ucwCR for ; Fri, 30 Aug 2013 11:01:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DCC3421F9D45 for ; Fri, 30 Aug 2013 11:01:55 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7UI1naM005363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Aug 2013 18:01:50 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UI1mxr020969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 18:01:49 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UI1m5r021346; Fri, 30 Aug 2013 18:01:48 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Aug 2013 11:01:48 -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: <0CD4C29A-464D-41C0-A57A-E203CB2BD5F4@brianrosen.net> Date: Fri, 30 Aug 2013 14:01:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <256B4395-C8E3-4382-A990-7BA13F73F970@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <56B55B95-F402-41BD-A19F-DD67933A525C@oracle.com! > <0CD4C29A-464D-41C0-A57A-E203CB2BD5F4@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "cnit@ietf.org" , Stephen Kent , Henning Schulzrinne 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: Fri, 30 Aug 2013 18:02:02 -0000 On Aug 30, 2013, at 1:07 PM, Brian Rosen wrote: > While I understand the problem you are pointing out, I don't think = it's anywhere near as bad as you are projecting it. I think in any = country, there are only a small number of suitable validation services. = I think that for any given recipient, knowing the in-country validators = is good enough, or at most the few neighbor country's validators. I = think that the most likely entities to actually deal with the value are = folks like Apple and Google, or Samsung and Nokia who create with the = received call UIs, and they could develop methods rate a few thousand = validators. I expect we will see meta-rating services that deal with = the problem also.=20 I agree there are a limited number of smartphone vendors. It would be = great to get them involved with any of this stuff (like involved in = STIR, for example). Unfortunately they don't appear to be involved. = And the smartphone market, while incredibly powerful and growing = dramatically, still only represents ~20% of call-receiving "phones". Furthermore, using an analogy with email: while getting native email = POP3/IMAP *clients* to do stuff is nice, in practice it's the SMTP email = servers that do a bulk of the work as far as I can tell. Whether they = be corporate servers like MS Exchange and the spam-filtering boxes, or = hosted ones like gmail, yahoo, and hotmail. ISTM that's pretty similar = to the SIP world of corporate IP-PBXs and the SIP Service Providers. > If the score is a scaler, then it's possible to derate a score if you = have a rating on the scoring service. I appreciate the business opportunity for SBCs to manipulate scores = based on the meaning and reputation of various validation services, but = I don't think it's a good idea. :) > Mostly I would say that having the score is infinitely better than not = having the score, even with the problem that state of the art today = doesn't let us have a more definitive mechanism. The reasons it's not infinitely better are the usual ones: complexity = and interoperability. Additional complexity for no gain is bad. = Additional interop issues are bad too, obviously. As far as I can tell, = the score would be a "do what I mean not what I say" model. =20 If we can't figure out what the code needs to look like for all actors = (the originating, terminating carriers, and verification service), by = definition we'll have an interop problem. If the code requires = operators to set different "derating" values based on who the far-end = validation service is, it's going to cause interop problems (or at least = the "operability" part of "interoperability"). If you want to put extra optional vendor-specific data in the "package" = that's up to you; optional vendor-specific extensions are done in CA = certs too. Just don't expect/require receivers to pay attention to it. = In my opinion the "base" CNIT mechanism should just either assert a = name->phone mapping, or not do so, for any given call/caller. -hadriel From hadriel.kaplan@oracle.com Fri Aug 30 11:17:09 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 7F0DA21F9E1A for ; Fri, 30 Aug 2013 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 5TsHUdrixe+m for ; Fri, 30 Aug 2013 11:17:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id F0B8B21F9E12 for ; Fri, 30 Aug 2013 11:17:02 -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 r7UIGt8h029204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Aug 2013 18:16:56 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UIGslo025294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 18:16:55 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UIGs9B012951; Fri, 30 Aug 2013 18:16:54 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Aug 2013 11:16:53 -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: Fri, 30 Aug 2013 14:16:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8449EA78-12FE-4559-BF2D-ED6DA0437013@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: cnit@ietf.org, Henning Schulzrinne , Stephen Kent , "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: Fri, 30 Aug 2013 18:17:09 -0000 On Aug 30, 2013, at 1:21 PM, Brian Rosen wrote: > You seem to be rejecting all ideas. Not at all - I'm debating the notion of call senders (or their = validation service agents) sending scores in a meaningful way to = everyone else. [As an aside, I think you might feel I'm yelling or getting frustrated = or whatever - I'm not. I want to figure out a plausible solution. The = way I do that is I posit a premise/idea/solution and try to pick holes = in it. You're proposing sending scores, and I'm saying I see problems = with that and trying to explain what those problems are. It's hard to = convey emotion/emphasis/volume in emails. This would go better in a = physical meeting methinks.] > If you don't like scoring and you don't like multiple names with = source, what do you like? Who said I didn't like "multiple names with source"? You lost me. Or = maybe I don't know what you mean by the words "multiple names with = source". I don't mind "scores", when it's a score generated by the terminating = domain (or an agent of their's) based on various inputs, for their own = use. That's all up to them to do/decide/control. There are no interop = issues, and the complexity is as much as they want it to be. > I don't think it's going to be hard to authorize third party use. It's not hard from the perspective of writing a spec or even writing = code. It's hard in the sense that it requires devices and people to do = things they didn't have to do before. Don't get me wrong - I want it to = be as trivially easy as possible, and I hope it will be used. But my = hunch is we don't really know all the variables that affect adoption of = third-party authorization, and some of those variables might lead to = having doctors call out "through" their office PBX. I don't think it's a = big deal if that happens though. I was just making a small comment = about that, is all. -hadriel From Henning.Schulzrinne@fcc.gov Fri Aug 30 11:21: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 4E4A621F9FDA for ; Fri, 30 Aug 2013 11:21:05 -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 GvIgO9hgLtdR for ; Fri, 30 Aug 2013 11:20:51 -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 5E9E521F9CF3 for ; Fri, 30 Aug 2013 11:20:50 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' , "dcrocker@bbiw.net" Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAADT0cAAAAyOIAAA4HxgAAA8nIAAAXKhIAAGcErgAAJNRGAAADvA4AAJ/PcgAABIWKAAAHSaIAACSfroAAgMUWAAAdH/AAAARmiAAAIVX+w///bygCAAApnAIAAAWeAgAAD3ACAAEG34A== Date: Fri, 30 Aug 2013 18:20:47 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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.net> In-Reply-To: <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.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 Kent , "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: Fri, 30 Aug 2013 18:21:05 -0000 I suspect we do need to distinguish two cases: (1) Company uses single caller/client evaluation. From what I've been told,= all the large financial companies do this, and they presumably spend the m= oney on this for a reason. Scoring and such are relatively straightforward,= as each company deals with one information service at a time. They can loo= k back at their fraud cases and say "if we lower the acceptance score a bit= , we can remove x% of fraud, but lose y% of legitimate customers." (2) Our any-to-any model. The recipient has no way of knowing what scoring = method the originator uses and what the scale might be. We also need to separate two use cases: (1) Inbound calls to companies. They can use existing tools and may not nee= d much in terms of name validation, although that can obviously help as an = additional source of data. They are probably most helped by STIR number val= idation. (For example, there are commercial outfits that try to estimate th= e location of the caller based on voice path characteristics, used by finan= cial institutions to identify non-US callers with US VoIP numbers.) (2) Inbound calls to individuals, particularly vulnerable populations, prim= arily from entities pretending to be a trustworthy organization, aided by t= hird-party filters. My main concern is the 2nd category although I obviously don't mind helping= the first. I'm less concerned with Eve Mallory pretending to be Jane Good,= i.e., another residential caller. This is a problem for spear-phishing and= thus worth solving, but less for large-scale fraud. However, the problem isn't nearly as intractable as for email for two reaso= ns: (1) The market is fairly concentrated (I'm not saying that as a good-thing = argument, but as a statement of fact). The top 13 companies have well in ex= cess of 80% of residential broadband customers. The top 100 companies are p= robably closer to 95% and the total number of consumer/business-facing carr= iers is a few thousand. Similar for wireless, except the number of companie= s is 4. That's even more true in other countries, where you don't tend to h= ave as many regionals. I suspect the concentration among consumer-facing large companies is even h= igher. A Fortune 500 company is unlikely to get its voice services from Joe= 's Broadband & Salvage. (2) And, importantly, most of the customers have an on-going financial rela= tionship with that provider, unlike for the dominant consumer email compani= es. That provides reasonable identity information based on billing records.= (The number of commercial voice customers who are buying scratch-off cards= at CVS with cash is probably pretty small.) Thus, while lessons from email are helpful, it's probably more interesting = to see if there are differences that can be exploited to make this more suc= cessful, at least for some significant fraction of the good calls. We all a= gree that the bad guys will continue to be able to find pink carriers. As l= ong as none of the bigger guys goes rogue, that's not a major concern as no= body will pay attention to what some fly-by-night outfit asserts. Also, the goal for name/property identification is not spam/SPIT prevention= as much as dealing with the fraudulent calls that survive the STIR spam fi= lter. So far, the proposed alternative seems to be a "live with it" approach.=20 Henning -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, August 30, 2013 1:41 PM To: dcrocker@bbiw.net Cc: cnit@ietf.org; Stephen Kent; Dwight, Timothy M (Tim); Henning Schulzrin= ne Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) Okay. We support dozens of customers who had serious fraud abuse until the= y started using our database to evaluate callers to their call center. Typ= ically, they query with 3-6 fields. They get a score back. They decide ho= w to handle the caller based on the score. Responses range from a polite g= oodbye to a what can we do to get your business, and lots in between. The = call taker doesn't often see the score directly - the call branch tree is m= odified automatically (what to ask, what to offer, what to accept, how to h= andle exceptions). I'd have to get some numbers to cite what the usual dec= line in fraud is, but we have lots of long term customers. The part of this that I can't cite a specific example for is what some clev= er UI developer will come up with to use the data. What I know is, it's us= eful, and we'll figure out a way. It might have binned responses. It migh= t change the response if this is the first call from the identity. It migh= t supply a thumbs up/down selection that is used for other callers. It mig= ht supply a Travelocity style rating. Dunno, but I have high confidence (w= ith moderate uncertainty) that folks like Apple and Google will figure out = a good UI to use the data. Brian On Aug 30, 2013, at 1:26 PM, Dave Crocker wrote: > On 8/30/2013 10:21 AM, Brian Rosen wrote: >> Hadriel >>=20 >> You seem to be rejecting all ideas. >=20 > Whereas you seem to be rejecting all concerns. >=20 >=20 > So, Brian and others who are convinced that this topic is straightforward= and easily amenable to effective mechanisms: >=20 > Please cite your evidence. >=20 > Look for other areas with a history of abuse that were significantly = mitigated by the approach you are espousing. >=20 > Over the course of my own involvement in anti-abuse, over the last 15 yea= rs, I know of none that qualifies. >=20 >=20 >=20 >> We seem to agree that within a country, there needs to be one database o= f credentials. >=20 > Oh? >=20 >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From hadriel.kaplan@oracle.com Fri Aug 30 11:28:09 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 9D02F11E8111 for ; Fri, 30 Aug 2013 11:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 h+fEC2jPRxwM for ; Fri, 30 Aug 2013 11:27:57 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3E24311E80FA for ; Fri, 30 Aug 2013 11:27:57 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7UIRler029471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Aug 2013 18:27:47 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UIRjdq019032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 18:27:46 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UIRjtN018837; Fri, 30 Aug 2013 18:27:45 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Aug 2013 11:27:45 -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: <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.net> Date: Fri, 30 Aug 2013 14:27:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <27FCCB7E-9A5C-43EF-B0A2-E407E9B88D6C@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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.ne! t > <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: cnit@ietf.org, Stephen Kent , "Dwight, Timothy M \(Tim\)" , dcrocker@bbiw.net, Henning Schulzrinne 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: Fri, 30 Aug 2013 18:28:10 -0000 On Aug 30, 2013, at 1:40 PM, 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. Typically, they query with 3-6 fields. They get a score back. = They decide how to handle the caller based on the score. Responses = range from a polite goodbye to a what can we do to get your business, = and lots in between. The call taker doesn't often see the score = directly - the call branch tree is modified automatically (what to ask, = what to offer, what to accept, how to handle exceptions). I'd have to = get some numbers to cite what the usual decline in fraud is, but we have = lots of long term customers. OK, then you've got a working solution. What's the problem you're = trying to solve then? What's the problem CNIT is trying to solve, if = these things are working fine? And if they're not working fine, in what = way are they not working fine? > 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. What I know is, = it's useful, and we'll figure out a way. 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. Dunno, = but I have high confidence (with moderate uncertainty) that folks like = Apple and Google will figure out a good UI to use the data. If your database is used by the terminating provider, which as far as I = know is the case, then ISTM that draft-wing-sipping-spam-score is the = solution to that. No? -hadriel From Henning.Schulzrinne@fcc.gov Fri Aug 30 11:30:40 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 7485221F9DAB for ; Fri, 30 Aug 2013 11:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_75=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 K-lRsiAzApuE for ; Fri, 30 Aug 2013 11:30:35 -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 3CFF821F8D0D for ; Fri, 30 Aug 2013 11:30:34 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAA6N0gAAACyEYAAALihAAADT0cAAAAyOIAAA4HxgAAA8nIAAAXKhIAAGcErgAAJNRGAAADvA4AAJ/PcgAABIWKAAAHSaIAACSfroAAgMUWAAAdH/AAAARmiAAAIVX+w///bygCAACdjMA== Date: Fri, 30 Aug 2013 18:30:33 +0000 References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> In-Reply-To: <9D3DF6A2-F2F0-4766-B9B3-EBCBAB3C4299@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" 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: Fri, 30 Aug 2013 18:30:40 -0000 You seem to assume that the carrier decides to suppress callerID informatio= n. For the reasons you hint at, that seems unlikely. My mental model is a t= hird-party provider (e.g., an app on a smartphone or a module in a PBX) tha= t takes the available information and uses that to make policy decisions. T= he recipient can choose the trade-offs. As I mentioned earlier, for a senio= r citizen, they might subscribe to the AARP service that only shows callerI= D provided by the organizations they trust. If you don't like that list, yo= u find another service. A bank PBX where the concern is phishing would appl= y a different policy and might, for example, be very careful about renderin= g organizational names that claim to be from a regulator or another bank. The presence of pink carriers is not that relevant here, as they'd never ma= ke it on the trust list of either example. -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Friday, August 30, 2013 12:45 PM To: Henning Schulzrinne Cc: Dwight, Timothy M (Tim); Brian Rosen; Stephen Kent; cnit@ietf.org Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller I= D) On Aug 30, 2013, at 11:05 AM, Henning Schulzrinne wrote: > I suspect you would need a "portable" mechanism, which then starts to loo= k awfully similar to certs where a CA-like entity (say, the home carrier in= our case) provides their customer with credentials that the customer can u= se outside that relationship. By analogy, this isn't altogether different f= rom the model of various identity-like cards, from a library card to a stud= ent ID, that are used outside their original context, but it raises all the= usual CA-like concerns. Some of these are mitigated if, DANE-like, the rec= eiving entity can validate that Verizon is indeed the carrier for a certain= phone number, so that trusting a Verizon-issued credential is reasonable. = Thus, you get a trust chain (among several possible): > Caller proves assignment of phone number --> phone number is mapped relia= bly to carrier --> carrier asserts limited attributes of customer I think the problem with this is that we know we can't trust the "carriers"= . That's how we got to STIR to begin with. I totally trust Verizon, and a= bunch of big carriers for that matter, but there are lots of SIP service "= providers", of various sizes and shades of pink. For example we know for a= fact that some "providers" are complicit in generating fake calling number= s *and* names - it's part of their business model. If we could decide which ones were bad purely on statistical reputation alo= ne, and stop displaying their numbers+names, then the STIR solution would b= e quite different... maybe even unnecessary. We know we can't do that for = political, legal, and operational/scalability reasons. That's why we think= doing STIR the way we've been talking about it is worth-while, presumably.= No? > Longer term, I wonder if the mediated call signaling model will become mo= re common, i.e., where the doctor's phone routes calls through an outbound = proxy in the office. That reduces the number of cases where you need such p= ortable credentials. Some of that happens already today, fwiw. I do expect it to become more co= mmon if STIR gets deployed, if it's non-trivial to authorize third-party so= urce identity use. -hadriel From br@brianrosen.net Fri Aug 30 11:31: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 91B6F11E810E for ; Fri, 30 Aug 2013 11:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.904 X-Spam-Level: X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_BIZOP=0.7, 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 alsDNPBZnOpt for ; Fri, 30 Aug 2013 11:31:43 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8F28F11E80FA for ; Fri, 30 Aug 2013 11:31:43 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id k8so1068961qcq.28 for ; Fri, 30 Aug 2013 11:31:42 -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=RrN8WthD+W2GfSwJIHO27eWj2894VriY02gQ0KQeXfQ=; b=Cm1M8/7GTiM/avVEz9dWEX+UziKs0Vp9pCtcX3RJyes8g6iyP5KgDSRiHnM5L+ll68 mouvXMXS9M6CSetM2h1tmzy2bj/vHOLhauBCZz69p9Kyg609xjGRE3m1YYK9jryTMkE+ 5QA6Ro/4FfvmXQWbBDSMQN4UUke9K8+D7gBnbny8+8FENZMuLr5a6f+SsnWqFv6B6zJ9 uWkuNbFvEELSuHEMRIQ849T+uLLSpWlYW/pwzAB+fCGD3sJ1JIleF8hG/Cr+XqM58yOB 94EoU3yLQ9RZ4XeS7XRsOlos7Cq1q7auyPBdQ6W/fKJnwYBnUJkR4AmWnJhMfZtzOHDm lsKQ== X-Gm-Message-State: ALoCoQlOvsu9BYDyWqPBIZCEmx0wEoTk5lxWEVa173FcwQrpo3sqCQyULXxD5i9ajW+gOlGc1Lec X-Received: by 10.224.151.145 with SMTP id c17mr1400043qaw.95.1377887501902; Fri, 30 Aug 2013 11:31:41 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id g3sm53705224qas.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 11:31:39 -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: <256B4395-C8E3-4382-A990-7BA13F73F970@oracle.com> Date: Fri, 30 Aug 2013 14:31:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <56B55B95-F402-41BD-A19F-DD67933A525C@oracle.com! > <0CD4C29A-464D-41C0-A57A-E203CB2BD5F4@brianrosen.net> <256B4395-C8E3-4382-A990-7BA13F73F970@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Stephen Kent , Henning Schulzrinne 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: Fri, 30 Aug 2013 18:31:49 -0000 If some devices do a better job of helping consumers deal with unknown = callers then those phones will succeed. =20 One of the reasons VoIP service is stuck at ATAs is that the service = can't provide any useful features beyond what POTS service does. If a = direct VoIP phone, not an ATA, provided better service, it may succeed = where ATAs are the norm.=20 Your email analogy is flawed in that the services that do the best, the = UI is done by someone who really does it well, and they provide = mechanisms that help users separate interesting mail from spam. Most of = these use web browser or smartphone/tablet UIs. It's the UI part that = matters, and that's not the email server in the sense we usually take = it. There is very little complexity in a simple scaler score. There is zero = interoperability issues. The problem is interpreting the score. That = isn't that the receiving device and the sending device disagree on how = to handle the score in the protocol. Ignoring the score is easy. = Interoperably transporting the score is easy. Interpreting it may be = more difficult. Brian On Aug 30, 2013, at 2:01 PM, Hadriel Kaplan = wrote: >=20 > On Aug 30, 2013, at 1:07 PM, Brian Rosen wrote: >=20 >> While I understand the problem you are pointing out, I don't think = it's anywhere near as bad as you are projecting it. I think in any = country, there are only a small number of suitable validation services. = I think that for any given recipient, knowing the in-country validators = is good enough, or at most the few neighbor country's validators. I = think that the most likely entities to actually deal with the value are = folks like Apple and Google, or Samsung and Nokia who create with the = received call UIs, and they could develop methods rate a few thousand = validators. I expect we will see meta-rating services that deal with = the problem also.=20 >=20 > I agree there are a limited number of smartphone vendors. It would be = great to get them involved with any of this stuff (like involved in = STIR, for example). Unfortunately they don't appear to be involved. = And the smartphone market, while incredibly powerful and growing = dramatically, still only represents ~20% of call-receiving "phones". >=20 > Furthermore, using an analogy with email: while getting native email = POP3/IMAP *clients* to do stuff is nice, in practice it's the SMTP email = servers that do a bulk of the work as far as I can tell. Whether they = be corporate servers like MS Exchange and the spam-filtering boxes, or = hosted ones like gmail, yahoo, and hotmail. ISTM that's pretty similar = to the SIP world of corporate IP-PBXs and the SIP Service Providers. >=20 >=20 >> If the score is a scaler, then it's possible to derate a score if you = have a rating on the scoring service. >=20 > I appreciate the business opportunity for SBCs to manipulate scores = based on the meaning and reputation of various validation services, but = I don't think it's a good idea. :) >=20 >=20 >> Mostly I would say that having the score is infinitely better than = not having the score, even with the problem that state of the art today = doesn't let us have a more definitive mechanism. >=20 > The reasons it's not infinitely better are the usual ones: complexity = and interoperability. Additional complexity for no gain is bad. = Additional interop issues are bad too, obviously. As far as I can tell, = the score would be a "do what I mean not what I say" model. =20 >=20 > If we can't figure out what the code needs to look like for all actors = (the originating, terminating carriers, and verification service), by = definition we'll have an interop problem. If the code requires = operators to set different "derating" values based on who the far-end = validation service is, it's going to cause interop problems (or at least = the "operability" part of "interoperability"). >=20 > If you want to put extra optional vendor-specific data in the = "package" that's up to you; optional vendor-specific extensions are done = in CA certs too. Just don't expect/require receivers to pay attention = to it. In my opinion the "base" CNIT mechanism should just either = assert a name->phone mapping, or not do so, for any given call/caller. >=20 > -hadriel >=20 From br@brianrosen.net Fri Aug 30 11:42:33 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 2E98E21F9FF9 for ; Fri, 30 Aug 2013 11:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.254 X-Spam-Level: X-Spam-Status: No, score=-103.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 Q+ShGj47YilY for ; Fri, 30 Aug 2013 11:42:27 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id A0E2211E8114 for ; Fri, 30 Aug 2013 11:42:18 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id j7so3561766qaq.6 for ; Fri, 30 Aug 2013 11:42:17 -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=0K4gKNVn0K6vJPPZoC5YVrIhXw0UISEMRzYLoxMe90M=; b=EBRwi6O5hXN8dkWuINmJ+/i+ZJ1YNw73VKHYZ1ZuISXGQaOJzuZG6Dty1hEvi9wV2O 84Ldper4adAz2MVXPvI1PthFsvMzly2dXEyXFH1v6ahyj81YRrB7kgNj3Dv6ukYIoBM2 dlrLB1IQyZATKNRjE6Rynl/hh1gETPgTAzj7jBcXIL4KG/49fwYF7exFjXQYfPWR7LZz NUNp78wXTD7JnN7Yq/94IoM0slkJhEat0eMYhAAKhnhiozq5OULZA9SgPMR14zq5RSFx VsLKB445YduLiaX2jKv6x4FZ3y7Ok0CX/BbdqMumstcrMkdUO8CKETw+4nYDK7lmVNUS ep6w== X-Gm-Message-State: ALoCoQme/UQZQdlKOR0wxJEBBgfVILT2LDtVLtzxSB2OZT4W5hqUs135hsc5xXQBMXht7SZFx5iZ X-Received: by 10.49.17.162 with SMTP id p2mr12784416qed.69.1377888137048; Fri, 30 Aug 2013 11:42:17 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id m5sm53809667qaa.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 11:42:15 -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: <27FCCB7E-9A5C-43EF-B0A2-E407E9B88D6C@oracle.com> Date: Fri, 30 Aug 2013 14:42:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <57D5AA0A-B9D2-47DA-8D98-3746422A7AE2@brianrosen.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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.ne! t > <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.net> <27FCCB7E-9A5C-43EF-B0A2-E407E9B88D6C@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: cnit@ietf.org, Stephen Kent , "Dwight, Timothy M \(Tim\)" , dcrocker@bbiw.net, Henning Schulzrinne 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: Fri, 30 Aug 2013 18:42:33 -0000 I'm trying to move scoring to the origination side, because I can get = more information to validate the name that I can at the termination = side. If I get more information, I can get better scores. At the = termination side, all I have is phone number. The complication, and the difference between this working example and = the cnit problem is what Henning called the any-to-any problem - if the = scoring is on the origination, then the termination has to evaluate the = validator to know how to deal with the score. I agree that makes it = more complex than what we have working. I think we probably can agree = that if there are a relatively small number of validators, then having = more than one is tractable, but if there are lots, then it isn't. I'm = arguing that for most cases, the reality will be okay - either the = terminating side will only be dealing with a few validators, because the = vast majority of calls are within a country, or at least within a few = neighboring countries, or the service used by the terminating side, = Google, Apple et. al. can deal with a couple thousand validators. On Aug 30, 2013, at 2:27 PM, Hadriel Kaplan = wrote: >=20 > On Aug 30, 2013, at 1:40 PM, Brian Rosen wrote: >=20 >> Okay. We support dozens of customers who had serious fraud abuse = until they started using our database to evaluate callers to their call = center. Typically, they query with 3-6 fields. They get a score back. = They decide how to handle the caller based on the score. Responses = range from a polite goodbye to a what can we do to get your business, = and lots in between. The call taker doesn't often see the score = directly - the call branch tree is modified automatically (what to ask, = what to offer, what to accept, how to handle exceptions). I'd have to = get some numbers to cite what the usual decline in fraud is, but we have = lots of long term customers. >=20 > OK, then you've got a working solution. What's the problem you're = trying to solve then? What's the problem CNIT is trying to solve, if = these things are working fine? And if they're not working fine, in what = way are they not working fine? >=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. What I know = is, it's useful, and we'll figure out a way. 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. Dunno, = but I have high confidence (with moderate uncertainty) that folks like = Apple and Google will figure out a good UI to use the data. >=20 > If your database is used by the terminating provider, which as far as = I know is the case, then ISTM that draft-wing-sipping-spam-score is the = solution to that. No? >=20 > -hadriel >=20 From hadriel.kaplan@oracle.com Fri Aug 30 11:42: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 14DBD21E808F for ; Fri, 30 Aug 2013 11:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 Cb-5uLr-zXOU for ; Fri, 30 Aug 2013 11:42:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C6F4211E811E for ; Fri, 30 Aug 2013 11:42:23 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7UIg8bI011045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Aug 2013 18:42:09 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UIg7OK009796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 18:42:07 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UIg6qX009777; Fri, 30 Aug 2013 18:42:06 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Aug 2013 11:42:06 -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: Fri, 30 Aug 2013 14:42:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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.ne! t > <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "cnit@ietf.org" , Stephen Kent , "Dwight, Timothy M \(Tim\)" , "dcrocker@bbiw.net" , '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: Fri, 30 Aug 2013 18:42:36 -0000 Not sure who you're directing it to, but... I am not proposing a "live = with it" solution. I'm trying to understand the problem, and trying to = figure out a solution. I'm poking holes in the balloons being floated, = to see if they burst. That's a pretty common way to design I think; at = least for me. And right now this whole topic truly is in the = research+design phase. Quite honestly I think some folks might be getting frustrated, but I = think that's because this debate is occurring in email. Email's not a = good medium for initial discussions like this. Even voice conf calls = aren't good for this. Maybe we should schedule a small contingent of = folks to get on Google hangouts? -hadriel On Aug 30, 2013, at 2:20 PM, Henning Schulzrinne = wrote: > I suspect we do need to distinguish two cases: >=20 > (1) Company uses single caller/client evaluation. =46rom what I've = been told, all the large financial companies do this, and they = presumably spend the money on this for a reason. Scoring and such are = relatively straightforward, as each company deals with one information = service at a time. They can look back at their fraud cases and say "if = we lower the acceptance score a bit, we can remove x% of fraud, but lose = y% of legitimate customers." >=20 > (2) Our any-to-any model. The recipient has no way of knowing what = scoring method the originator uses and what the scale might be. >=20 > We also need to separate two use cases: >=20 > (1) Inbound calls to companies. They can use existing tools and may = not need much in terms of name validation, although that can obviously = help as an additional source of data. They are probably most helped by = STIR number validation. (For example, there are commercial outfits that = try to estimate the location of the caller based on voice path = characteristics, used by financial institutions to identify non-US = callers with US VoIP numbers.) >=20 > (2) Inbound calls to individuals, particularly vulnerable populations, = primarily from entities pretending to be a trustworthy organization, = aided by third-party filters. >=20 > My main concern is the 2nd category although I obviously don't mind = helping the first. I'm less concerned with Eve Mallory pretending to be = Jane Good, i.e., another residential caller. This is a problem for = spear-phishing and thus worth solving, but less for large-scale fraud. >=20 > However, the problem isn't nearly as intractable as for email for two = reasons: >=20 > (1) The market is fairly concentrated (I'm not saying that as a = good-thing argument, but as a statement of fact). The top 13 companies = have well in excess of 80% of residential broadband customers. The top = 100 companies are probably closer to 95% and the total number of = consumer/business-facing carriers is a few thousand. Similar for = wireless, except the number of companies is 4. That's even more true in = other countries, where you don't tend to have as many regionals. >=20 > I suspect the concentration among consumer-facing large companies is = even higher. A Fortune 500 company is unlikely to get its voice services = from Joe's Broadband & Salvage. >=20 > (2) And, importantly, most of the customers have an on-going financial = relationship with that provider, unlike for the dominant consumer email = companies. That provides reasonable identity information based on = billing records. (The number of commercial voice customers who are = buying scratch-off cards at CVS with cash is probably pretty small.) >=20 > Thus, while lessons from email are helpful, it's probably more = interesting to see if there are differences that can be exploited to = make this more successful, at least for some significant fraction of the = good calls. We all agree that the bad guys will continue to be able to = find pink carriers. As long as none of the bigger guys goes rogue, = that's not a major concern as nobody will pay attention to what some = fly-by-night outfit asserts. >=20 > Also, the goal for name/property identification is not spam/SPIT = prevention as much as dealing with the fraudulent calls that survive the = STIR spam filter. >=20 > So far, the proposed alternative seems to be a "live with it" = approach.=20 >=20 > Henning >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, August 30, 2013 1:41 PM > To: dcrocker@bbiw.net > Cc: cnit@ietf.org; Stephen Kent; Dwight, Timothy M (Tim); Henning = Schulzrinne > Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual = caller ID) >=20 > Okay. We support dozens of customers who had serious fraud abuse = until they started using our database to evaluate callers to their call = center. Typically, they query with 3-6 fields. They get a score back. = They decide how to handle the caller based on the score. Responses = range from a polite goodbye to a what can we do to get your business, = and lots in between. The call taker doesn't often see the score = directly - the call branch tree is modified automatically (what to ask, = what to offer, what to accept, how to handle exceptions). I'd have to = get some numbers to cite what the usual decline in fraud is, but we have = lots of long term customers. >=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. What I know is, = it's useful, and we'll figure out a way. 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. Dunno, = but I have high confidence (with moderate uncertainty) that folks like = Apple and Google will figure out a good UI to use the data. >=20 > Brian From br@brianrosen.net Fri Aug 30 11:43:19 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 D1F2F21F9FF9 for ; Fri, 30 Aug 2013 11:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.262 X-Spam-Level: X-Spam-Status: No, score=-103.262 tagged_above=-999 required=5 tests=[AWL=0.337, 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 g8Kf+60oC8ut for ; Fri, 30 Aug 2013 11:43:14 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6E8E21F9967 for ; Fri, 30 Aug 2013 11:43:13 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so1173892qeb.17 for ; Fri, 30 Aug 2013 11:43: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=7lj0rfitfLJrAAMhy7fn5ryHbZM9pT6HVUXSFpp1G1M=; b=ZeCQRWASMOsonZlBNI7qjwFHutVXXwF2Psnz8GPAUPGwIPbSv3EalShLhiAAUNymW4 6kBUiwsUZvSMQVQ1Li7n31R5Iv/6N0+jJMtN3dkXDcIZWjLNlOzQ7lPtpUJYtKTzeCna Dt1PqnSoom082BMIOu45YctsDGBN+xxCDpOmNe7R2e8gAOEuS5Mxw93hqeL91S51yWQR aEE0admiVgr3o/OIAcYWgkm88BjaQoHoRVc5JHyAswghyz1pGsHIPTdmMD8EkEjrRM+G 5qZv44G7FixvmyFuSMIRp9IWzNf6IYVMKG7kYUHOY4A8X9HfsdUAozG4P/7XnCpX5Iwt P9zA== X-Gm-Message-State: ALoCoQk9YglNSu9Vfw8xjAtNME05K6heC7xXX42fStK9mGEUBl0RPw5boScN3Q8J2WB5+W5uRoLC X-Received: by 10.224.103.73 with SMTP id j9mr5214909qao.101.1377888193180; Fri, 30 Aug 2013 11:43:13 -0700 (PDT) Received: from [10.33.193.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id m5sm53809667qaa.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 11:43:12 -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: Fri, 30 Aug 2013 14:43:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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.ne! t > <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "cnit@ietf.org" , Stephen Kent , "Dwight, Timothy M \(Tim\)" , "dcrocker@bbiw.net" , Henning Schulzrinne 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: Fri, 30 Aug 2013 18:43:19 -0000 I am willing. Brian On Aug 30, 2013, at 2:42 PM, Hadriel Kaplan = wrote: >=20 > Not sure who you're directing it to, but... I am not proposing a "live = with it" solution. I'm trying to understand the problem, and trying to = figure out a solution. I'm poking holes in the balloons being floated, = to see if they burst. That's a pretty common way to design I think; at = least for me. And right now this whole topic truly is in the = research+design phase. >=20 > Quite honestly I think some folks might be getting frustrated, but I = think that's because this debate is occurring in email. Email's not a = good medium for initial discussions like this. Even voice conf calls = aren't good for this. Maybe we should schedule a small contingent of = folks to get on Google hangouts? >=20 > -hadriel >=20 >=20 > On Aug 30, 2013, at 2:20 PM, Henning Schulzrinne = wrote: >=20 >> I suspect we do need to distinguish two cases: >>=20 >> (1) Company uses single caller/client evaluation. =46rom what I've = been told, all the large financial companies do this, and they = presumably spend the money on this for a reason. Scoring and such are = relatively straightforward, as each company deals with one information = service at a time. They can look back at their fraud cases and say "if = we lower the acceptance score a bit, we can remove x% of fraud, but lose = y% of legitimate customers." >>=20 >> (2) Our any-to-any model. The recipient has no way of knowing what = scoring method the originator uses and what the scale might be. >>=20 >> We also need to separate two use cases: >>=20 >> (1) Inbound calls to companies. They can use existing tools and may = not need much in terms of name validation, although that can obviously = help as an additional source of data. They are probably most helped by = STIR number validation. (For example, there are commercial outfits that = try to estimate the location of the caller based on voice path = characteristics, used by financial institutions to identify non-US = callers with US VoIP numbers.) >>=20 >> (2) Inbound calls to individuals, particularly vulnerable = populations, primarily from entities pretending to be a trustworthy = organization, aided by third-party filters. >>=20 >> My main concern is the 2nd category although I obviously don't mind = helping the first. I'm less concerned with Eve Mallory pretending to be = Jane Good, i.e., another residential caller. This is a problem for = spear-phishing and thus worth solving, but less for large-scale fraud. >>=20 >> However, the problem isn't nearly as intractable as for email for two = reasons: >>=20 >> (1) The market is fairly concentrated (I'm not saying that as a = good-thing argument, but as a statement of fact). The top 13 companies = have well in excess of 80% of residential broadband customers. The top = 100 companies are probably closer to 95% and the total number of = consumer/business-facing carriers is a few thousand. Similar for = wireless, except the number of companies is 4. That's even more true in = other countries, where you don't tend to have as many regionals. >>=20 >> I suspect the concentration among consumer-facing large companies is = even higher. A Fortune 500 company is unlikely to get its voice services = from Joe's Broadband & Salvage. >>=20 >> (2) And, importantly, most of the customers have an on-going = financial relationship with that provider, unlike for the dominant = consumer email companies. That provides reasonable identity information = based on billing records. (The number of commercial voice customers who = are buying scratch-off cards at CVS with cash is probably pretty small.) >>=20 >> Thus, while lessons from email are helpful, it's probably more = interesting to see if there are differences that can be exploited to = make this more successful, at least for some significant fraction of the = good calls. We all agree that the bad guys will continue to be able to = find pink carriers. As long as none of the bigger guys goes rogue, = that's not a major concern as nobody will pay attention to what some = fly-by-night outfit asserts. >>=20 >> Also, the goal for name/property identification is not spam/SPIT = prevention as much as dealing with the fraudulent calls that survive the = STIR spam filter. >>=20 >> So far, the proposed alternative seems to be a "live with it" = approach.=20 >>=20 >> Henning >>=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: Friday, August 30, 2013 1:41 PM >> To: dcrocker@bbiw.net >> Cc: cnit@ietf.org; Stephen Kent; Dwight, Timothy M (Tim); Henning = Schulzrinne >> Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual = caller ID) >>=20 >> Okay. We support dozens of customers who had serious fraud abuse = until they started using our database to evaluate callers to their call = center. Typically, they query with 3-6 fields. They get a score back. = They decide how to handle the caller based on the score. Responses = range from a polite goodbye to a what can we do to get your business, = and lots in between. The call taker doesn't often see the score = directly - the call branch tree is modified automatically (what to ask, = what to offer, what to accept, how to handle exceptions). I'd have to = get some numbers to cite what the usual decline in fraud is, but we have = lots of long term customers. >>=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. What I know = is, it's useful, and we'll figure out a way. 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. Dunno, = but I have high confidence (with moderate uncertainty) that folks like = Apple and Google will figure out a good UI to use the data. >>=20 >> Brian From alex@bobotek.net Fri Aug 30 11:49: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 E959321E808E for ; Fri, 30 Aug 2013 11:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 xhEHhgt8O7Jg for ; Fri, 30 Aug 2013 11:49:22 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id A779421F9FF9 for ; Fri, 30 Aug 2013 11:49:22 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta13.emeryville.ca.mail.comcast.net with comcast id K64o1m0060QkzPwAD6pNKT; Fri, 30 Aug 2013 18:49:22 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta02.emeryville.ca.mail.comcast.net with comcast id K6pL1m00S4EJ4tY8N6pMXd; Fri, 30 Aug 2013 18:49:21 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Fri, 30 Aug 2013 11:41:46 -0700 From: Alex Bobotek To: "dcrocker@bbiw.net" , Hadriel Kaplan Date: Fri, 30 Aug 2013 11:41:45 -0700 Thread-Topic: [cnit] [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6lo2V0S/xiFcUjRh2sifgixNRjlgABhhbw Message-ID: <4B1956260CD29F4A9622F00322FE053193812973E8@BOBO1A.bobotek.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> <56B55B95-F402-41BD-A19F-DD67933A525C@oracle.com> <5220D2B0.3000601@dcrocker.net> In-Reply-To: <5220D2B0.3000601@dcrocker.net> 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377888562; bh=a4okFgdDAvmtfciTnkJ66k3dSxAMzw/9gFc3XVI2kkg=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=KCQqDxLT/TJhqUnOOfav9rrg4Yho52A4b1TZP8LxJGOyCt/6ymHE8BktKatMdJP4d eTUiD+44RiN1opStEyJE+Nrt2KO/q07KUmXM4LpWCbqBllt1vOWxH+jxexewrKnl5N 09K62GjZg3R6DYJk23VB0HyfY5pb+tXr9fVPN7qVA2SxqR3UcgD5FAO9HMtQvfddP2 /Ke0W9B3rqdNyj1AHuJCNDEEHsdbgnXBRf9zw697h5dMTO9TxcUfhnL61rpqoR+sx6 fD6rqC2xuhUtuL2Np+tZqTcbJlaIPe2XXcNMgYrSSq14j8g43jUtKnTfEOQcZokjMz EDVGkqZZmVNCw== Cc: "cnit@ietf.org" , 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: Fri, 30 Aug 2013 18:49:27 -0000 Dave wrote: =20 > Over the last 15 years, there have been a number of startup company effor= ts > to "empower' end-users with quality assessment information. > Essentially all have failed. > 1. What has succeeded is incorporating end-user preferences into a termina= ting service provider's filtering. IMHO, this (terminating SP filters, bas= ed on subscriber prefs) is the most important call/message acceptance decis= ion model. In some cases this filtering may be extended to the user agen= t (e.g., if a user chooses to), where _automata_ acting on the behalf of th= e end-user may consume reputation information. =20 2. (A separate point, not in response to Dave's comment) Calling party dis= play name as we know it (unstructured text) cannot provide sufficient infor= mation to prevent vishing, fraud, smishing and robocalling. Adding structu= re to originating SP assertions does not solve this, as they cannot be comp= elled or trusted to provide accurate infomation. I believe reputation asso= ciated with an identity is also needed, and that CNIT Display Name efforts = should not expect nor attempt to obviate other necessary reputation informa= tion (e.g., terminating SP and 3rd party info). Some sort of optional 'fac= ts I know about the Display Name' assertion by the originating SP make sens= e. However, there is clearly some security value in controlling display na= mes. =20 Regards, Alex > -----Original Message----- > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of > Dave Crocker > Sent: Friday, August 30, 2013 10:13 AM > To: Hadriel Kaplan > Cc: cnit@ietf.org; Brian Rosen > Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller= ID) >=20 > On 8/30/2013 9:28 AM, Hadriel Kaplan wrote: > > > > I think I'm repeating myself, but maybe if I say it differently it > > will be clearer... > > > > The challenge with sending a score is that the receiver (a) can't > > believe it, and (b) doesn't know what it truly means relative to the > > receiver's notion of score values. >=20 > +1 >=20 >=20 > > Afaik, today email spam systems do have notions of score, but it's > > something the receivers create themselves - it's under the control and > > policy decision of the receiver. >=20 > Receivers have very complex filtering engines, typically with /layers/ of= many > different scores, based on a variety of attributes, and factored into hig= hly > contingent analysis engines. >=20 > Users never see any of this; the engines feed into basic handling choices= , > such as inbox vs. spam folder. >=20 > Over the last 15 years, there have been a number of startup company effor= ts > to "empower' end-users with quality assessment information. > Essentially all have failed. >=20 > The only report I've heard of real efficacy was at Yahoo, where they boil= ed it > down to a trust/don't-trust/don't-know distinction, but this certainly ha= s not > gained traction in the industry. >=20 > References to thinks like EV certs could benefit from some reporting on > efficacy; my impression is that they've had no effect on end-users, any m= ore > than the lock symbol at the bottom of the web page. >=20 >=20 > > What you're proposing for CNIT is a reputation-based naming >=20 > An essential point from many years of email reputation -- and by the way > way, physical world reputation -- is the need for multiple and potentiall= y > competing services. >=20 >=20 > > There is something like this in the email world, fwiw: RFC 5518 > > vouch-by-reference. I don't know if it's used or not in the real > > world, but its assertion is a lot simpler and more constrained. >=20 > VBR isn't used. Reasonable idea, but no market traction. >=20 > And then there's the more recent Repute working group that is just finish= ing > up: >=20 > http://datatracker.ietf.org/wg/repute/ >=20 > On the average, folks tend to approach abuse remediation with an > assumption that it is tractable to assertion of a bit more control and th= at that > isn't difficult. >=20 > On the average, that hasn't produced encouraging results. >=20 >=20 > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From kent@bbn.com Fri Aug 30 18:27:42 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 C6E9621F9EB6 for ; Fri, 30 Aug 2013 18:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 rObPE6a43XC8 for ; Fri, 30 Aug 2013 18:27:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D286B21F9E4F for ; Fri, 30 Aug 2013 18:27:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:48140 helo=[IPv6:::1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VFZyP-0009OF-F0; Fri, 30 Aug 2013 21:27:33 -0400 Message-ID: <52214684.6020301@bbn.com> Date: Fri, 30 Aug 2013 21:27:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian Rosen References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> <61E614C6-950C-48A1-BDB2-242519DE71C3@brianrosen.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> In-Reply-To: <0E552CE9-DE70-4B45-B230-EC9E68DDCDDE@brianrosen.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "cnit@ietf.org" 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: Sat, 31 Aug 2013 01:27:42 -0000 Brian, >> I also have come to question the motives of some of the most vocal proponents of such >> systems, wondering if their employers may be financial beneficiaries of this >> technical approach. > I assume that is directed at me. if the shoe fits ... > While true that my employer has such capability and would stand to make money on the idea, that problem exists, in spades, with the entire stir effort. I, for one, don't have a financial stake in this, so I disagree. I get paid by clients to track security-relevant standards activities and try to encourage good outcomes. > Nevertheless, I would not be pushing the idea if I did not personally think this will be of great value to the caller. You have no basis to question my sincerity. I used the term motives, not sincerity. > I submit that it is exceedingly hard for any entity to provide a name with certainty anywhere near the level of certainty we generally assume when we state values. you may generally assume, not me. I know that the sort of names that people informally use to identify individuals and orgs are not globally unique, and I try to warn people about the pitfalls of creating systems that may mislead the consumers of such IDs. > We will be able to state with some large degree of certainty that the phone number is correct. agreed. > We will have MUCH less certainty of the name, and wide variation of certainty, no matter what we do. To assume, or say otherwise is foolish. agreed. > When you have varying levels of certainty, it helps, a lot, to have an idea of HOW certain you are. I will give you an example in another domain. When we report your location as latitude/longitude based on some measurement, there is both uncertainty (we know you are within some area, say a radius around a point) and confidence (what is the probability you are in that circle), which we have ways of expressing. In location, unlike names, we have ways of measuring confidence and uncertainty. the ability to measure the uncertainty re location accuracy, and the underpinnings in physics, are very important differences, which call into question your analogy. > ... > > You may be aware of this thing called "Big Data Analytics". There is science behind scoring data like what I'm advocating, but we're still pretty much at the beginning of understanding it. and you don't find that worrisome? > What is not so hard, is using it. Lots and lots of companies and researchers are successfully using the data, for applications not so dissimilar from what we're discussing. I find it ironic that at a time when so many people are aghast at revelations about NSA acquisition of communication metadata, we're assuming that creating an even bigger market for commercially-acquired metadata is a good idea. > ... > > Sending a score is cheap. Make it optional if you wish. Sending a score is cheap for the SPs. If one considers the potential for confusion for users, I come to a different conclusion. Steve From dhc@dcrocker.net Sat Aug 31 12:35: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 3391E11E816D for ; Sat, 31 Aug 2013 12:35:51 -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 RiucUIzwGm8N for ; Sat, 31 Aug 2013 12:35:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02111E8163 for ; Sat, 31 Aug 2013 12:35:46 -0700 (PDT) Received: from [172.29.102.244] (wsip-184-191-162-57.sd.sd.cox.net [184.191.162.57]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7VJZZoq017290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 31 Aug 2013 12:35:39 -0700 Message-ID: <52224580.6030901@dcrocker.net> Date: Sat, 31 Aug 2013 12:35:28 -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: Brian Rosen 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> In-Reply-To: <3593A59C-E90F-42BE-BF46-ABF5877B37D2@brianrosen.net> 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]); Sat, 31 Aug 2013 12:35:40 -0700 (PDT) Cc: cnit@ietf.org, "Dwight, Timothy M \(Tim\)" , Stephen Kent , Henning Schulzrinne 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 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: Sat, 31 Aug 2013 19:35:51 -0000 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. 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. > Typically, they query with 3-6 fields. They get a > score back. They decide how to handle the caller based on the score. 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. > 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. 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. 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. In fact, the essential difference is between having a software policy engine with built-in rulesets, versus a 'wet' real-time policy formulation engine. > What I > know is, it's useful, and we'll figure out a way. 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. > 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. So it turns out that what you've described is considerably more than clever UI design. 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. 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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Sat Aug 31 14:20:10 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 15E9D11E8190 for ; Sat, 31 Aug 2013 14:20:10 -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=[AWL=-0.000, 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 t8IvjOo6sS4Q for ; Sat, 31 Aug 2013 14:20:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE5311E8191 for ; Sat, 31 Aug 2013 14:20:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BD565BEA4 for ; Sat, 31 Aug 2013 22:20:02 +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 j1rMyxPk3W+z for ; Sat, 31 Aug 2013 22:20:02 +0100 (IST) Received: from [10.87.48.15] (unknown [86.46.20.4]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 321E5BE9C for ; Sat, 31 Aug 2013 22:20:02 +0100 (IST) Message-ID: <52225DF8.4000000@cs.tcd.ie> Date: Sat, 31 Aug 2013 22:19:52 +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: "cnit@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [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: Sat, 31 Aug 2013 21:20:10 -0000 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.