From nobody Tue Jun 2 09:26:24 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686B81AD379 for ; Tue, 2 Jun 2015 09:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.079 X-Spam-Level: X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsRC8VXeLXAP for ; Tue, 2 Jun 2015 09:26:21 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FF31A002D for ; Tue, 2 Jun 2015 09:26:20 -0700 (PDT) Received: by qcej9 with SMTP id j9so18786477qce.1 for ; Tue, 02 Jun 2015 09:26:20 -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:message-id:references:to; bh=JiG6ngPhE/DadJJq0ZNhQ8e/doOYvqzTsmPdiWbvGI0=; b=R2hZgMCjdzqstA9PJEr3wSIJP3oGKFBS4/YqfE3iKeOjma+KxH5/LOHK4LmljBKxud XmK0IANMUoBl0DFJ7jZ0AfuKtvlPxi607OytocrqdNsH51S0Toq4KwCCW+1TqoyrOtC0 SwyLeZEP22Ww24rBpDOtTnW31xeriamXB75jILZpGQBf2N9zAvxPQEtJsTV53RpiJQD9 DnM34l+DWC6ztRnG/W6SBsFFIhfQfmdTsiSMi6ZAr9Y2yaqmUWVZRBo+hAsYyCa9ijFR tCS9ccdUuC4VwzY0j05bdLHBDYgkss1nth7xOOiqHYFpssA4K+2LPnJVPW/GvfssfIBD dSVQ== X-Gm-Message-State: ALoCoQnq8ue8iGfCO9onGGSl76atYqx7ICPU2h2DeeKYYLVBcW3WH/w+NESPO1v3BWqR0rtBcIdJ X-Received: by 10.140.16.173 with SMTP id 42mr30350501qgb.31.1433262379904; Tue, 02 Jun 2015 09:26:19 -0700 (PDT) Received: from [10.33.192.46] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id j66sm7584159qgj.8.2015.06.02.09.26.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jun 2015 09:26:18 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B295D6BD-5133-4201-B548-7C7A7CC73DF6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Brian Rosen In-Reply-To: Date: Tue, 2 Jun 2015 12:26:15 -0400 Message-Id: References: To: Richard Shockey X-Mailer: Apple Mail (2.2098) Archived-At: Cc: cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:26:23 -0000 --Apple-Mail=_B295D6BD-5133-4201-B548-7C7A7CC73DF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Are we planning to submit a charter in the next couple of days, and then = see if we can get a slot at the next IETF? Brian > On May 28, 2015, at 1:55 PM, Richard Shockey = wrote: >=20 >=20 > A fair argument but I don=92t want to spend 5 years waiting for a = series of normative dependencies on the trust model before actually = understanding what headers can/should be used here.=20 >=20 >=20 > Its much too difficult to get things done in the IETF as it is. I=92d = much prefer building from success starting with the definition of the = data object then ..then folding that into a trust model and frankly = given what we have seen in STIR I=92m not sure your argument holds up. = Again the MARTINI model. >=20 > Didn=92t you recently say something about =93perfection is the enemy = of the good=94 :-)=20 >=20 >=20 >=20 > From: Eric Burger > > Date: Wednesday, May 27, 2015 at 10:11 PM > To: > > Subject: Re: [cnit] CNIT Charter bashing.. >=20 > On May 25, 2015, at 5:31 PM, Richard Shockey > wrote: >>=20 >> From: Mary Barnes > >> Date: Friday, May 22, 2015 at 12:58 PM >> Attached is what I have at this point. Really, the only thing I'm = struggling with is the milestones as I don't think we can request = publication of the data object and headers without having defined the = trust model.=20 >>=20 >>=20 >> RS> Mary I=92m not sure about that statement. I can certainly = anticipate several deployment models where the trust mechanism (aka = signing) does not need to be formally integrated in the solution = especially those where the exchange of data is more bi-lateral and the = trust mechanism is at lower layers of the stack than the signaling. My = initial concern is what is the header and what is the data object(s) = carried in the header. How the CNIT data is created should not be our = concern. >=20 > I do not buy it. If there are private agreements between service = providers, they have private agreements. They can do whatever they want. >=20 > Last I looked, this is the Internet Engineering Task Force. Assume = untrusted transport across the wide open Internet, and trust no endpoint = that cannot cryptographically prove who they are. If it happens two = service providers exchange CNIT data over a single, yellow cable, then = it is a benefit that no state-sponsored security service can listen in = on the cable. >=20 > I do not want to take three years to build a protocol and two more = years after that for products to be available just to have a system that = only works in walled gardens. I do not want to be the person that has to = explain to the media why Calling Name Delivery is just as broken as it = always was and it will be another five years before the world sees a = real solution. >=20 > Let us get this right the first time. > [snip] > _______________________________________________ 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 --Apple-Mail=_B295D6BD-5133-4201-B548-7C7A7CC73DF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Are we planning to submit a charter in the next couple of = days, and then see if we can get a slot at the next IETF?

Brian
On = May 28, 2015, at 1:55 PM, Richard Shockey <richard@shockey.us> = wrote:


A fair argument but I = don=92t want to spend 5 years waiting for a series of normative = dependencies on the trust model before actually understanding what = headers can/should be used here. 


Its = much too difficult to get things done in the IETF as it is.   I=92d = much prefer building from success starting with the definition of the = data object then ..then folding that into a trust model and frankly = given what we have seen in STIR I=92m not sure your argument holds up. = Again the MARTINI model.

Didn=92t you recently  say something about =93perfection = is the enemy of the good=94  :-) 



From: Eric Burger <eburger@standardstrack.com>
Date: Wednesday, May 27, = 2015 at 10:11 PM
To: <cnit@ietf.org>
Subject: Re: [cnit] CNIT = Charter bashing..

On May 25, 2015, at = 5:31 PM, Richard Shockey <richard@shockey.us> wrote:

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Friday, May 22, 2015 = at 12:58 PM
Attached is = what I have at this point. Really, the only thing I'm struggling with is = the milestones as I don't think we can request publication of the data = object and headers without having defined the trust = model. 


RS> Mary I=92m not = sure about that statement. I can certainly anticipate several deployment = models where the trust mechanism (aka signing) does not need to be = formally integrated in the solution especially those where the exchange = of data is more bi-lateral and the trust mechanism is at lower layers of = the stack than the signaling. My initial concern  is what is the = header and what is the data object(s) carried in the header. How the = CNIT data is created should not be our = concern.

I do not buy it. If there are private agreements = between service providers, they have private agreements. They can do = whatever they want.

Last I looked, this is the Internet Engineering Task Force. Assume untrusted = transport across the wide open Internet, and trust no endpoint that = cannot cryptographically prove who they are. If it happens two service = providers exchange CNIT data over a single, yellow cable, then it is a = benefit that no state-sponsored security service can listen in on the = cable.

I do = not want to take three years to build a protocol and two more years = after that for products to be available just to have a system that only = works in walled gardens. I do not want to be the person that has to = explain to the media why Calling Name Delivery is just as broken as it = always was and it will be another five years before the world sees a = real solution.

Let us get this right the first time.
[snip]
_________________________________= ______________ 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

= --Apple-Mail=_B295D6BD-5133-4201-B548-7C7A7CC73DF6-- From nobody Tue Jun 2 09:55:42 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2DD1A6EF1 for ; Tue, 2 Jun 2015 09:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.382 X-Spam-Level: ** X-Spam-Status: No, score=2.382 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foJFeB596PZd for ; Tue, 2 Jun 2015 09:55:37 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id A48271B3432 for ; Tue, 2 Jun 2015 09:55:37 -0700 (PDT) Received: (qmail 27301 invoked by uid 0); 2 Jun 2015 16:55:37 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy5.mail.unifiedlayer.com with SMTP; 2 Jun 2015 16:55:37 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id baUf1q00T1MNPNq01aUi8k; Tue, 02 Jun 2015 16:28:45 -0600 X-Authority-Analysis: v=2.1 cv=d9Vml3TE c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=HLLxP2VMAAAA:8 a=bfLuiRfvAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=rVJLarO3Jijctql1XjoA:9 a=DHqZKblqtk1asM1G:21 a=eJa_48NMxDuTL5zB:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=PRbaxNLCZWG2UeMc41kA:9 a=5opRPf3ef9wBm6ni:21 a=5cgQo5oj_-PiFvCz:21 a=DLxVWb4qe9OfuVm4:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=4z/CovSqXQO0EZWv5w8OPsOreXqUroCgKq7/7Gyjx/8=; b=JmAs99PAGfUF+YZQ83lh+kRrYQc7b+VlY0BQ1WqmQPUVsiISyP3ls6wNI1B9JVoyW7rBc7qbT2dW03h6WImz++QY2AiqZCF2Y+ldVkGHf/zQGZxTxGvf3ouzfE95aCBM; Received: from [108.56.131.149] (port=54979 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YzpA3-0007Kl-8i; Tue, 02 Jun 2015 10:35:31 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Tue, 02 Jun 2015 12:35:27 -0400 From: Richard Shockey To: Brian Rosen Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3516093331_419067" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Cc: cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:55:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3516093331_419067 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hopefully but I still haven=B9t seen any response to my concern about normative dependencies on STIR. If we can define the object/headers first then I don=B9t have a issue. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey Cc: Eric Burger , Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian > On May 28, 2015, at 1:55 PM, Richard Shockey wrote: >=20 >=20 > A fair argument but I don=B9t want to spend 5 years waiting for a series of > normative dependencies on the trust model before actually understanding w= hat > headers can/should be used here. >=20 >=20 > Its much too difficult to get things done in the IETF as it is. I=B9d muc= h > prefer building from success starting with the definition of the data obj= ect > then ..then folding that into a trust model and frankly given what we hav= e > seen in STIR I=B9m not sure your argument holds up. Again the MARTINI model= . >=20 > Didn=B9t you recently say something about =B3perfection is the enemy of the = good=B2 > :-)=20 >=20 >=20 >=20 > From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM > To: > Subject: Re: [cnit] CNIT Charter bashing.. >=20 > On May 25, 2015, at 5:31 PM, Richard Shockey wrote: >>=20 >> From: Mary Barnes >> Date: Friday, May 22, 2015 at 12:58 PM >> Attached is what I have at this point. Really, the only thing I'm strugg= ling >> with is the milestones as I don't think we can request publication of th= e >> data object and headers without having defined the trust model. >>=20 >>=20 >> RS> Mary I=B9m not sure about that statement. I can certainly anticipate >> several deployment models where the trust mechanism (aka signing) does n= ot >> need to be formally integrated in the solution especially those where th= e >> exchange of data is more bi-lateral and the trust mechanism is at lower >> layers of the stack than the signaling. My initial concern is what is t= he >> header and what is the data object(s) carried in the header. How the CNI= T >> data is created should not be our concern. >=20 > I do not buy it. If there are private agreements between service provider= s, > they have private agreements. They can do whatever they want. >=20 > Last I looked, this is the Internet Engineering Task Force. Assume untrus= ted > transport across the wide open Internet, and trust no endpoint that canno= t > cryptographically prove who they are. If it happens two service providers > exchange CNIT data over a single, yellow cable, then it is a benefit that= no > state-sponsored security service can listen in on the cable. >=20 > I do not want to take three years to build a protocol and two more years = after > that for products to be available just to have a system that only works i= n > walled gardens. I do not want to be the person that has to explain to the > media why Calling Name Delivery is just as broken as it always was and it= will > be another five years before the world sees a real solution. >=20 > Let us get this right the first time. > [snip] > _______________________________________________ cnit mailing list > cnit@ietf.orghttps://www.ietf.org/mailman/listinfo/cnit > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit --B_3516093331_419067 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

Hope= fully but I still haven’t seen any response to my concern about normat= ive dependencies on STIR.

If we can define the obje= ct/headers first then I don’t have a issue.

<= div>— 
Richard Shockey
Shockey Consulting LLC=
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Lin= kedin-Facebook rshockey101
PSTN +1 703-593-2683


From: = Brian Rosen <br@brianrosen.net>= ;
Date: Tuesday, June 2, 2015 at 1= 2:26 PM
To: Richard Shockey <richard@shockey.us>
Cc: Eric Burger <eburger@standardstrack.com>, <cnit@ietf.org>
Subject: <= /span> Re: [cnit] CNIT Charter bashing..

Are we planning to submit a charter in the next cou= ple of days, and then see if we can get a slot at the next IETF?

Brian
On May 28, 2015, at 1:55 PM, Richard Shockey &l= t;richard@shockey.us> wr= ote:


A fair= argument but I don’t want to spend 5 years waiting for a series of no= rmative dependencies on the trust model before actually understanding what h= eaders can/should be used here. 

=

Its much too difficult to get= things done in the IETF as it is.   I’d much prefer building fro= m success starting with the definition of the data object then ..then foldin= g that into a trust model and frankly given what we have seen in STIR I̵= 7;m not sure your argument holds up. Again the MARTINI model.

Didn’t you recently  say so= mething about “perfection is the enemy of the good”  :-)&nb= sp;


<= div class=3D"">

From: Eric Burger <eburger@standardstrack.co= m>
Date: = Wednesday, May 27, 2015 at 10:11 PM
To: <cnit@iet= f.org>
Subject: <= /span> Re: [cnit] CNIT Charter bashing..
On May= 25, 2015, at 5:31 PM, Richard Shockey <richard@shockey.us> wrote:

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Friday, May 22,= 2015 at 12:58 PM
Attached is what= I have at this point. Really, the only thing I'm struggling with is the mil= estones as I don't think we can request publication of the data object and h= eaders without having defined the trust model. 


RS> = Mary I’m not sure about that statement. I can certainly anticipate sev= eral deployment models where the trust mechanism (aka signing) does not need= to be formally integrated in the solution especially those where the exchan= ge of data is more bi-lateral and the trust mechanism is at lower layers of = the stack than the signaling. My initial concern  is what is the header= and what is the data object(s) carried in the header. How the CNIT data is = created should not be our concern.

I do not buy it. If there are private agreements betwe= en service providers, they have private agreements. They can do whatever the= y want.

Last I looked, this is= the Internet Engineering Task Force. Assume untru= sted transport across the wide open Internet, and trust no endpoint that can= not cryptographically prove who they are. If it happens two service provider= s exchange CNIT data over a single, yellow cable, then it is a benefit that = no state-sponsored security service can listen in on the cable.

I do not want to take three years to= build a protocol and two more years after that for products to be available= just to have a system that only works in walled gardens. I do not want to b= e the person that has to explain to the media why Calling Name Delivery is j= ust as broken as it always was and it will be another five years before the = world sees a real solution.

Let us get this right the first time.
[snip]
_______________________________________________ cnit mailing list cnit@ietf.orghttps://www.ietf.org/mailman/lis= tinfo/cnit
_______________________________________________
cnit mailing li= st
cnit@ietf.org
https://www.ie= tf.org/mailman/listinfo/cnit

 --B_3516093331_419067-- From nobody Wed Jun 10 20:21:02 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B201A8AD9 for ; Wed, 10 Jun 2015 20:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGu3oL8b160C for ; Wed, 10 Jun 2015 20:20:57 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 080CB1A8AD6 for ; Wed, 10 Jun 2015 20:20:57 -0700 (PDT) Received: (qmail 22348 invoked by uid 0); 11 Jun 2015 03:20:53 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy4.mail.unifiedlayer.com with SMTP; 11 Jun 2015 03:20:53 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id eqqR1q00S1MNPNq01qqUEz; Wed, 10 Jun 2015 20:50:32 -0600 X-Authority-Analysis: v=2.1 cv=GeGEw2nL c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=OTLVf7z5AAAA:8 a=HLLxP2VMAAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=bfLuiRfvAAAA:8 a=pGLkceISAAAA:8 a=pTp3KH0DkuwnvPPZkXIA:9 a=7WpG-JsKzxAEaojT:21 a=NAd7dgEMnUAWhLWR:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=a5WBIJHMAqT_G6dV7MUA:9 a=ZEup93SSFD_LuiZP:21 a=aIjKl2gKz_7UQwyC:21 a=-enn1C7fokHk4SPf:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=G826bO00Cnav65HfMEXa8NGgt8GSUv1UEQx7yFyRT+4=; b=nZX/pGc1Z1MhyyLNvGdx+1vEMTPl92QlauRvkLT9RCu0P3ZpzMcGQwME3eRyEOXTwxQAzbasXOF7K9ozglf8vf7p33bFPEd87bL2UcysmDiSgYpvWOphMA5IFtHayueT; Received: from [108.56.131.149] (port=49992 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z2sjW-0007Lo-E2; Wed, 10 Jun 2015 21:00:46 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Wed, 10 Jun 2015 23:00:42 -0400 From: Richard Shockey To: Brian Rosen , Henning Schulzrinne Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3516822046_2505314" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Cc: cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 03:21:01 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3516822046_2505314 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Here is what I want to know now. Before we start to process this concept I want to know how relevant the existing CNAM service is deployed outside North America. I=B9m told by reliable sources that the CNAM service is not deployed anywhere among the major telecom markets in Europe or Asia. Not Japan China or South Korea UK Italy France and in fact it might actually be illegal under the strict privacy regulations in Germany. I don=B9t know.=20 That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would b= e responsible for defining how the VoLTE CUA could actually display an advanced call display data and frankly no one knows. http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= - 6 There is a realistic question if this is simply a North American specific problem why is this a IETF issue. You might ask the same question of MODER= N but I frankly don=B9t want to go there. From: Richard Shockey Date: Tuesday, June 2, 2015 at 12:35 PM To: Brian Rosen Cc: Subject: Re: [cnit] CNIT Charter bashing.. Hopefully but I still haven=B9t seen any response to my concern about normative dependencies on STIR. If we can define the object/headers first then I don=B9t have a issue. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey Cc: Eric Burger , Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian > On May 28, 2015, at 1:55 PM, Richard Shockey wrote: >=20 >=20 > A fair argument but I don=B9t want to spend 5 years waiting for a series of > normative dependencies on the trust model before actually understanding w= hat > headers can/should be used here. >=20 >=20 > Its much too difficult to get things done in the IETF as it is. I=B9d muc= h > prefer building from success starting with the definition of the data obj= ect > then ..then folding that into a trust model and frankly given what we hav= e > seen in STIR I=B9m not sure your argument holds up. Again the MARTINI model= . >=20 > Didn=B9t you recently say something about =B3perfection is the enemy of the = good=B2 > :-)=20 >=20 >=20 >=20 > From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM > To: > Subject: Re: [cnit] CNIT Charter bashing.. >=20 > On May 25, 2015, at 5:31 PM, Richard Shockey wrote: >>=20 >> From: Mary Barnes >> Date: Friday, May 22, 2015 at 12:58 PM >> Attached is what I have at this point. Really, the only thing I'm strugg= ling >> with is the milestones as I don't think we can request publication of th= e >> data object and headers without having defined the trust model. >>=20 >>=20 >> RS> Mary I=B9m not sure about that statement. I can certainly anticipate >> several deployment models where the trust mechanism (aka signing) does n= ot >> need to be formally integrated in the solution especially those where th= e >> exchange of data is more bi-lateral and the trust mechanism is at lower >> layers of the stack than the signaling. My initial concern is what is t= he >> header and what is the data object(s) carried in the header. How the CNI= T >> data is created should not be our concern. >=20 > I do not buy it. If there are private agreements between service provider= s, > they have private agreements. They can do whatever they want. >=20 > Last I looked, this is the Internet Engineering Task Force. Assume untrus= ted > transport across the wide open Internet, and trust no endpoint that canno= t > cryptographically prove who they are. If it happens two service providers > exchange CNIT data over a single, yellow cable, then it is a benefit that= no > state-sponsored security service can listen in on the cable. >=20 > I do not want to take three years to build a protocol and two more years = after > that for products to be available just to have a system that only works i= n > walled gardens. I do not want to be the person that has to explain to the > media why Calling Name Delivery is just as broken as it always was and it= will > be another five years before the world sees a real solution. >=20 > Let us get this right the first time. > [snip] > _______________________________________________ cnit mailing list > cnit@ietf.orghttps://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 --B_3516822046_2505314 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable


Here is what I want to know now.

Before we start to process this concept I want to know how r= elevant the existing CNAM service is deployed outside North America.

I’m told by reliable sources that the CNAM service i= s not deployed anywhere among the major telecom markets in Europe or Asia. N= ot Japan China or South Korea UK Italy France and in fact it might actually = be illegal under the strict privacy regulations in Germany.

I don’t know. 

That said our fr= iends at Apple seem to understand there is a problem here. I have tried to e= ngage the most senior management at Google about who would be responsible fo= r defining how the VoLTE CUA could actually display an advanced call display= data and frankly no one knows. 


There is a realistic= question if this is simply a North American specific problem why is this &n= bsp;a IETF issue. You might ask the same question of MODERN but I frankly do= n’t want to go there.




From: Richard Shockey &= lt;richard@shockey.us>
Date: Tuesday, June 2, 2015 at 12:35 PM
<= span style=3D"font-weight:bold">To: Brian Rosen <br@brianrosen.net>
Cc: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing= ..


Hopefully but I still haven’t seen any response to my concern a= bout normative dependencies on STIR.

If we can defi= ne the object/headers first then I don’t have a issue.

<= /div>
— 
Richard Shockey
Shockey Con= sulting LLC
Chairman of the Board SIP Forum
www.shockey.= us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


Fr= om: Brian Rosen <br@brianrosen= .net>
Date: Tuesday, June 2= , 2015 at 12:26 PM
To: Richard Sho= ckey <richard@shockey.us>
<= span style=3D"font-weight:bold">Cc: Eric Burger <eburger@standardstrack.com>, <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

=
Are we planning to submit a charter in t= he next couple of days, and then see if we can get a slot at the next IETF?<= div class=3D"">
Brian
On May 28, 2015, at 1:55 PM, Richard= Shockey <richard@shockey.us= > wrote:


A fair argument but I don’t want to spend 5 years waiting for a s= eries of normative dependencies on the trust model before actually understan= ding what headers can/should be used here. 


Its much too diffi= cult to get things done in the IETF as it is.   I’d much prefer b= uilding from success starting with the definition of the data object then ..= then folding that into a trust model and frankly given what we have seen in = STIR I’m not sure your argument holds up. Again the MARTINI model.

Didn’t you recently &= nbsp;say something about “perfection is the enemy of the good” &= nbsp;:-) 



<= span id=3D"OLK_SRC_BODY_SECTION" class=3D"">
From: Eric Bu= rger <eburger@standa= rdstrack.com>
Dat= e: Wednesday, May 27, 2015 at 10:11 PM
To: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

On May 25, 2015, at 5:31 PM, Richard Shockey <richard@shockey.us> wrote:

= From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Frid= ay, May 22, 2015 at 12:58 PM
Attac= hed is what I have at this point. Really, the only thing I'm struggling with= is the milestones as I don't think we can request publication of the data o= bject and headers without having defined the trust model. 
=


RS> Mary I’m not sure about that statement. I can certainly ant= icipate several deployment models where the trust mechanism (aka signing) do= es not need to be formally integrated in the solution especially those where= the exchange of data is more bi-lateral and the trust mechanism is at lower= layers of the stack than the signaling. My initial concern  is what is= the header and what is the data object(s) carried in the header. How the CN= IT data is created should not be our concern.
=

I do not buy it. If there are private agree= ments between service providers, they have private agreements. They can do w= hatever they want.

Last I look= ed, this is the Internet Engineering Task Force. A= ssume untrusted transport across the wide open Internet, and trust no endpoi= nt that cannot cryptographically prove who they are. If it happens two servi= ce providers exchange CNIT data over a single, yellow cable, then it is a be= nefit that no state-sponsored security service can listen in on the cable.

I do not want to take thr= ee years to build a protocol and two more years after that for products to b= e available just to have a system that only works in walled gardens. I do no= t want to be the person that has to explain to the media why Calling Name De= livery is just as broken as it always was and it will be another five years = before the world sees a real solution.

Let us get this right the first time.
[sni= p]
_______________________________________________ cnit mailing list cnit@ietf.orghttps://www.ietf.org/mailman/lis= tinfo/cnit
_______________________________________________
cnit mailing li= st
cnit@ietf.org
https://www.ie= tf.org/mailman/listinfo/cnit

_______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/m= ailman/listinfo/cnit --B_3516822046_2505314-- From nobody Thu Jun 11 04:17:42 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F37D1A1B2A for ; Thu, 11 Jun 2015 04:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AGideVY19Du for ; Thu, 11 Jun 2015 04:17:37 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4681A1B27 for ; Thu, 11 Jun 2015 04:17:36 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 05e69755.2b5f1e696940.68867.00-2447.191719.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 11 Jun 2015 11:17:36 +0000 (UTC) X-MXL-Hash: 55796e50455aa424-ab26014bfca73e0798ab53b02cc8741282c6018e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 44e69755.0.68750.00-2313.191394.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 11 Jun 2015 11:17:25 +0000 (UTC) X-MXL-Hash: 55796e453762e0f9-fc071f7a750335088e8a878479101cc69c4d443c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5BBHNr7024935; Thu, 11 Jun 2015 07:17:23 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5BBHGdK024885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jun 2015 07:17:18 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 11 Jun 2015 11:16:56 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0224.002; Thu, 11 Jun 2015 07:16:56 -0400 From: "DOLLY, MARTIN C" To: Richard Shockey , Brian Rosen , Henning Schulzrinne Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQo/Wmd4mIgS3m+kqeJkvhgMQzyp2nKEEQ Date: Thu, 11 Jun 2015 11:16:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.170.154] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365603611F84MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NdFRIR/4 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=57hriNzNDrAA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=OTLVf7z5AA] X-AnalysisOut: [AA:8 a=HLLxP2VMAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=] X-AnalysisOut: [bfLuiRfvAAAA:8 a=pGLkceISAAAA:8 a=a5WBIJHMAqT_G6dV7MUA:9 a] X-AnalysisOut: [=CjuIK1q_8ugA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQY] X-AnalysisOut: [h4w-RC7EA:10 a=h7FFQaHNOm0A:10 a=-FEs8UIgK8oA:10 a=NWVoK91] X-AnalysisOut: [CQyQA:10 a=YjslTbWl2Kh1mXfy:21 a=AgCM2ckP_584_VTE:21 a=yMh] X-AnalysisOut: [MjlubAAAA:8 a=SSmOFEACAAAA:8 a=tUPRzhJqMJBkg069AVcA:9 a=gK] X-AnalysisOut: [O2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4Au] X-AnalysisOut: [Cg-hUA:10 a=HcZJvQPTZL6vOaws:21 a=3D7E5WQWfelHWsfl:21 a=kS] X-AnalysisOut: [lJqWJs9iNENKBn:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 11:17:41 -0000 --_000_E42CCDDA6722744CB241677169E8365603611F84MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Richard this is my understanding. From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, June 10, 2015 11:01 PM To: Brian Rosen; Henning Schulzrinne Cc: cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. Here is what I want to know now. Before we start to process this concept I want to know how relevant the exi= sting CNAM service is deployed outside North America. I'm told by reliable sources that the CNAM service is not deployed anywhere= among the major telecom markets in Europe or Asia. Not Japan China or Sout= h Korea UK Italy France and in fact it might actually be illegal under the = strict privacy regulations in Germany. I don't know. That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would= be responsible for defining how the VoLTE CUA could actually display an ad= vanced call display data and frankly no one knows. http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= -6 There is a realistic question if this is simply a North American specific p= roblem why is this a IETF issue. You might ask the same question of MODERN= but I frankly don't want to go there. From: Richard Shockey > Date: Tuesday, June 2, 2015 at 12:35 PM To: Brian Rosen > Cc: > Subject: Re: [cnit] CNIT Charter bashing.. Hopefully but I still haven't seen any response to my concern about normati= ve dependencies on STIR. If we can define the object/headers first then I don't have a issue. - Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen > Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey > Cc: Eric Burger >, > Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian On May 28, 2015, at 1:55 PM, Richard Shockey > wrote: A fair argument but I don't want to spend 5 years waiting for a series of n= ormative dependencies on the trust model before actually understanding what= headers can/should be used here. Its much too difficult to get things done in the IETF as it is. I'd much = prefer building from success starting with the definition of the data objec= t then ..then folding that into a trust model and frankly given what we hav= e seen in STIR I'm not sure your argument holds up. Again the MARTINI model= . Didn't you recently say something about "perfection is the enemy of the go= od" :-) From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM To: > Subject: Re: [cnit] CNIT Charter bashing.. On May 25, 2015, at 5:31 PM, Richard Shockey > wrote: From: Mary Barnes > Date: Friday, May 22, 2015 at 12:58 PM Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the= data object and headers without having defined the trust model. RS> Mary I'm not sure about that statement. I can certainly anticipate seve= ral deployment models where the trust mechanism (aka signing) does not need= to be formally integrated in the solution especially those where the excha= nge of data is more bi-lateral and the trust mechanism is at lower layers o= f the stack than the signaling. My initial concern is what is the header a= nd what is the data object(s) carried in the header. How the CNIT data is c= reated should not be our concern. I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want. Last I looked, this is the Internet Engineering Task Force. Assume untruste= d transport across the wide open Internet, and trust no endpoint that canno= t cryptographically prove who they are. If it happens two service providers= exchange CNIT data over a single, yellow cable, then it is a benefit that = no state-sponsored security service can listen in on the cable. I do not want to take three years to build a protocol and two more years af= ter that for products to be available just to have a system that only works= in walled gardens. I do not want to be the person that has to explain to t= he media why Calling Name Delivery is just as broken as it always was and i= t will be another five years before the world sees a real solution. Let us get this right the first time. [snip] _______________________________________________ cnit mailing list cnit@ietf= .orghttps://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 --_000_E42CCDDA6722744CB241677169E8365603611F84MISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard this is my understanding.

 

From: cnit [mailto:cnit-bounces@ietf= .org] On Behalf Of Richard Shockey
Sent: Wednesday, June 10, 2015 11:01 PM
To: Brian Rosen; Henning Schulzrinne
Cc: cnit@ietf.org
Subject: Re: [cnit] CNIT Charter bashing..

 

 

 

Here is what I want to know now.

 

Before we start to process this concept= I want to know how relevant the existing CNAM service is deployed outside = North America.

 

I’m told by reliable sources that= the CNAM service is not deployed anywhere among the major telecom markets = in Europe or Asia. Not Japan China or South Korea UK Italy France and in fact it might actually be illegal under the strict pri= vacy regulations in Germany.

 

I don’t know. 

 

That said our friends at Apple seem to = understand there is a problem here. I have tried to engage the most senior = management at Google about who would be responsible for defining how the VoLTE CUA could actually display an advanced call dis= play data and frankly no one knows. 

 

 

There is a realistic question if this is simply a North Ameri= can specific problem why is this  a IETF issue. You might ask the same= question of MODERN but I frankly don’t want to go there.

 

 

 

 

From: Richard Shockey <richard@shockey.us>
Date: Tuesday, June 2, 2015 at 12:35 PM
To: Brian Rosen <br@brianros= en.net>
Cc: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

 

Hopefully but I still haven’t see= n any response to my concern about normative dependencies on STIR.

 

If we can define the object/headers fir= st then I don’t have a issue.

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

richard<at>shockey.us<= /span>

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

 

 

From: Brian Rosen <br@brianrosen.net>
Date: Tuesday, June 2, 2015 at 12:26 PM
To: Richard Shockey <richar= d@shockey.us>
Cc: Eric Burger <eb= urger@standardstrack.com>, <cnit= @ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

Are we planning to submit a charter in = the next couple of days, and then see if we can get a slot at the next IETF= ?

 

Brian

On May 28, 2015, at 1:55 PM, Richard Sh= ockey <richard@shockey.us> = wrote:

 

 

A fair argument but I don’t want = to spend 5 years waiting for a series of normative dependencies on the trus= t model before actually understanding what headers can/should be used here. 

 

 

Its much too difficult to get things do= ne in the IETF as it is.   I’d much prefer building from success= starting with the definition of the data object then ..then folding that into a trust model and frankly given what we have seen in STI= R I’m not sure your argument holds up. Again the MARTINI model.<= /o:p>

 

Didn’t you recently  say som= ething about “perfection is the enemy of the good”  :-)&nb= sp;

 

 

 

From: Eric Burger <eburger@standardstrack.com>
Date: Wednesday, May 27, 2015 at 10:11 PM
To: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

On May 25, 2015, at 5:31 PM, Richard Sh= ockey <richard@shockey.us> = wrote:

 

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Friday, May 22, 2015 at 12:58 PM

Attached is what I have at this point. = Really, the only thing I'm struggling with is the milestones as I don't thi= nk we can request publication of the data object and headers without having defined the trust model. 

 

 

RS> Mary I’m not sure about th= at statement. I can certainly anticipate several deployment models where th= e trust mechanism (aka signing) does not need to be formally integrated in the solution especially those where the exchange of data is = more bi-lateral and the trust mechanism is at lower layers of the stack tha= n the signaling. My initial concern  is what is the header and what is= the data object(s) carried in the header. How the CNIT data is created should not be our concern.<= /p>

 

I do not buy it. If there are private a= greements between service providers, they have private agreements. They can= do whatever they want.

 

Last I looked, this is the Inte= rnet Engineering Task Force. Assume untrusted transport across the= wide open Internet, and trust no endpoint that cannot cryptographically prove who they are. If it happens two service providers exchange CNIT data= over a single, yellow cable, then it is a benefit that no state-sponsored = security service can listen in on the cable.

 

I do not want to take three years to bu= ild a protocol and two more years after that for products to be available j= ust to have a system that only works in walled gardens. I do not want to be the person that has to explain to the media w= hy Calling Name Delivery is just as broken as it always was and it will be = another five years before the world sees a real solution.=

 

Let us get this right the first time.

[snip]

_______________________________________= ________ cnit mailing list cnit@ietf.orghttps://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

--_000_E42CCDDA6722744CB241677169E8365603611F84MISOUT7MSGUSRDB_-- From nobody Thu Jun 11 06:02:31 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2211ACEF3 for ; Thu, 11 Jun 2015 06:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dok705cbYUZr for ; Thu, 11 Jun 2015 06:02:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B07E1ACEF0 for ; Thu, 11 Jun 2015 06:02:23 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id CC2B62DC5A0 for ; Thu, 11 Jun 2015 15:02:21 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AB72B23806E for ; Thu, 11 Jun 2015 15:02:21 +0200 (CEST) Received: from OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%18]) with mapi id 14.03.0235.001; Thu, 11 Jun 2015 15:02:21 +0200 From: To: "cnit@ietf.org" Thread-Topic: RE : [cnit] CNIT Charter bashing.. Thread-Index: AQHQpEbZR5lOjW4OW0a/A0/1NwUhqA== Date: Thu, 11 Jun 2015 13:02:20 +0000 Message-ID: <11535_1434027741_557986DD_11535_6458_1_s7ab2xtvudexwkabb1j3kk9d.1434027701687@email.android.com> References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_s7ab2xtvudexwkabb1j3kk9d1434027701687emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.11.123316 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 13:02:30 -0000 --_000_s7ab2xtvudexwkabb1j3kk9d1434027701687emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Richard, For a number of years, there has been an optional caller name dispay featur= e attached to some of the telephone services in France, but indeed nothing = like the standalone CNAM service concept that underpins the discussions on = this list. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Richard Shockey Date :11/06/2015 05:21 (GMT+01:00) =C0 : Brian Rosen , Henning Schulzrinne Cc : cnit@ietf.org Objet : Re: [cnit] CNIT Charter bashing.. Here is what I want to know now. Before we start to process this concept I want to know how relevant the exi= sting CNAM service is deployed outside North America. I=92m told by reliable sources that the CNAM service is not deployed anywhe= re among the major telecom markets in Europe or Asia. Not Japan China or So= uth Korea UK Italy France and in fact it might actually be illegal under th= e strict privacy regulations in Germany. I don=92t know. That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would= be responsible for defining how the VoLTE CUA could actually display an ad= vanced call display data and frankly no one knows. http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= -6 There is a realistic question if this is simply a North American specific p= roblem why is this a IETF issue. You might ask the same question of MODERN= but I frankly don=92t want to go there. From: Richard Shockey > Date: Tuesday, June 2, 2015 at 12:35 PM To: Brian Rosen > Cc: > Subject: Re: [cnit] CNIT Charter bashing.. Hopefully but I still haven=92t seen any response to my concern about norma= tive dependencies on STIR. If we can define the object/headers first then I don=92t have a issue. =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen > Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey > Cc: Eric Burger >, > Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian On May 28, 2015, at 1:55 PM, Richard Shockey > wrote: A fair argument but I don=92t want to spend 5 years waiting for a series of= normative dependencies on the trust model before actually understanding wh= at headers can/should be used here. Its much too difficult to get things done in the IETF as it is. I=92d muc= h prefer building from success starting with the definition of the data obj= ect then ..then folding that into a trust model and frankly given what we h= ave seen in STIR I=92m not sure your argument holds up. Again the MARTINI m= odel. Didn=92t you recently say something about =93perfection is the enemy of th= e good=94 :-) From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM To: > Subject: Re: [cnit] CNIT Charter bashing.. On May 25, 2015, at 5:31 PM, Richard Shockey > wrote: From: Mary Barnes > Date: Friday, May 22, 2015 at 12:58 PM Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the= data object and headers without having defined the trust model. RS> Mary I=92m not sure about that statement. I can certainly anticipate se= veral deployment models where the trust mechanism (aka signing) does not ne= ed to be formally integrated in the solution especially those where the exc= hange of data is more bi-lateral and the trust mechanism is at lower layers= of the stack than the signaling. My initial concern is what is the header= and what is the data object(s) carried in the header. How the CNIT data is= created should not be our concern. I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want. Last I looked, this is the Internet Engineering Task Force. Assume untruste= d transport across the wide open Internet, and trust no endpoint that canno= t cryptographically prove who they are. If it happens two service providers= exchange CNIT data over a single, yellow cable, then it is a benefit that = no state-sponsored security service can listen in on the cable. I do not want to take three years to build a protocol and two more years af= ter that for products to be available just to have a system that only works= in walled gardens. I do not want to be the person that has to explain to t= he media why Calling Name Delivery is just as broken as it always was and i= t will be another five years before the world sees a real solution. Let us get this right the first time. [snip] _______________________________________________ cnit mailing list cnit@ietf= .orghttps://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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_s7ab2xtvudexwkabb1j3kk9d1434027701687emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Richard,

For a number of years, there has been an optional caller name dispay f= eature attached to some of the telephone services in France, but indeed not= hing like the standalone CNAM service concept that underpins the discussion= s on this list.

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13


-------- Message d'origine --------
De : Richard Shockey
Date :11/06/2015 05:21 (GMT+01:00)
=C0 : Brian Rosen , Henning Schulzrinne
Cc : cnit@ietf.org
Objet : Re: [cnit] CNIT Charter bashing..



Here is what I want to know now.

Before we start to process this concept I want to know how relevant th= e existing CNAM service is deployed outside North America.

I=92m told by reliable sources that the CNAM service is not deployed a= nywhere among the major telecom markets in Europe or Asia. Not Japan China = or South Korea UK Italy France and in fact it might actually be illegal und= er the strict privacy regulations in Germany.

I don=92t know. 

That said our friends at Apple seem to understand there is a problem h= ere. I have tried to engage the most senior management at Google about who = would be responsible for defining how the VoLTE CUA could actually display = an advanced call display data and frankly no one knows. 


There is a realistic question if this i= s simply a North American specific problem why is this  a IETF issue. = You might ask the same question of MODERN but I frankly don=92t want to go = there.




From: Richard Shockey <richard@shockey.us>
Date: Tuesday, June 2, 2015 at 12:3= 5 PM
To: Brian Rosen <br@brianrosen.net>
Cc: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter ba= shing..


Hopefully but I still haven=92t seen any response to my concern about = normative dependencies on STIR.

If we can define the object/headers first then I don=92t have a issue.=

=97 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From: Brian Rosen <br@brianrosen.net>
Date: Tuesday, June 2, 2015 at 12:2= 6 PM
To: Richard Shockey <richard@shockey.us>
Cc: Eric Burger <eburger@standardstrack.com>, <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter ba= shing..

Are we planning to submit a = charter in the next couple of days, and then see if we can get a slot at th= e next IETF?

Brian
On May 28, 2015, at 1:55 PM, Richard Shockey <richard@shockey.us> wrote:

A fair argument but I don=92t want to spend 5 years waiting= for a series of normative dependencies on the trust model before actually = understanding what headers can/should be used here. 


Its much too difficult to get things done in the IETF as it= is.   I=92d much prefer building from success starting with the defin= ition of the data object then ..then folding that into a trust model and fr= ankly given what we have seen in STIR I=92m not sure your argument holds up. Again the MARTINI model.

Didn=92t you recently  say something about =93perfecti= on is the enemy of the good=94  :-) 



From: Eric Burger <eburger@standardstra= ck.com>
Date: Wednesday, May 27,= 2015 at 10:11 PM
To: <cnit@ietf.org>
Subject: Re: [cnit] CNIT= Charter bashing..

On May 25, 2015, at 5:31 PM,= Richard Shockey <richa= rd@shockey.us> wrote:

From: Mary Barnes <mary.ietf.barnes@gma= il.com>
Date: Friday, May 22, 20= 15 at 12:58 PM
Attached is what I have at this point. Really, = the only thing I'm struggling with is the milestones as I don't think we ca= n request publication of the data object and headers without having defined= the trust model. 


RS> Mary I=92m not sure about that statement. I can cert= ainly anticipate several deployment models where the trust mechanism (aka s= igning) does not need to be formally integrated in the solution especially = those where the exchange of data is more bi-lateral and the trust mechanism is at lower layers of the stack than th= e signaling. My initial concern  is what is the header and what is the= data object(s) carried in the header. How the CNIT data is created should = not be our concern.

I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want.

Last I looked, this is the Internet&= nbsp;Engineering Task Force. Assume untrusted transport across the wide ope= n Internet, and trust no endpoint that cannot cryptographically prove who t= hey are. If it happens two service providers exchange CNIT data over a single, yellow cable, then it is a benefit that no state-= sponsored security service can listen in on the cable.

I do not want to take three years to build a protocol and t= wo more years after that for products to be available just to have a system= that only works in walled gardens. I do not want to be the person that has= to explain to the media why Calling Name Delivery is just as broken as it always was and it will be another fi= ve years before the world sees a real solution.

Let us get this right the first time.
[snip]
_______________________________________________ cnit mailing list cnit@ietf.orghttps://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 ht= tps://www.ietf.org/mailman/listinfo/cnit 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_s7ab2xtvudexwkabb1j3kk9d1434027701687emailandroidcom_-- From nobody Thu Jun 11 09:06:28 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E0B1A87F2 for ; Thu, 11 Jun 2015 09:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI2mcy5to5xf for ; Thu, 11 Jun 2015 09:06:22 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 1506D1A8824 for ; Thu, 11 Jun 2015 09:06:22 -0700 (PDT) Received: (qmail 23551 invoked by uid 0); 11 Jun 2015 16:06:17 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy1.mail.unifiedlayer.com with SMTP; 11 Jun 2015 16:06:17 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id f3br1q0041MNPNq013buji; Thu, 11 Jun 2015 09:35:56 -0600 X-Authority-Analysis: v=2.1 cv=GeGEw2nL c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=OTLVf7z5AAAA:8 a=HLLxP2VMAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=bfLuiRfvAAAA:8 a=pGLkceISAAAA:8 a=xBHlremKZtAfUEJyL9sA:9 a=W7bBkmr4QrpzJf9E:21 a=O5y2k12a3gTCFwzn:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=4eWCkRgB1oGDSgTaHH4A:9 a=5h4N63yFId4Taz3F:21 a=90uGDOKcrn2wMW6m:21 a=713HbsW164x3WRym:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:To:From:Subject:Date; bh=iE+JRQVptrnjgUuyG+Jkp/xgmBMMLK21BF8q9/CQ5YQ=; b=au4Gcvpx4ftOl0Ra4J9pvPJQ07J2LNqJYBe5MZeiEK1LDaHvcSjNuYIt/SNZctLuLVWa313ssi+WcXet/y50ZaDbPhcCnSh1/E7n3luZqcNbMqpAP1lpLoCLlt2I9SEY; Received: from [108.56.131.149] (port=50397 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z34gF-0003rS-SH; Thu, 11 Jun 2015 09:46:12 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Thu, 11 Jun 2015 11:46:07 -0400 From: Richard Shockey To: , "cnit@ietf.org" Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3516867971_78554" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:06:27 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3516867971_78554 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thank you that is very helpful. I=B9m assuming its network delivered based on information derived from the calling party billing data. My other running assumption has been that some form Advanced Calling Name Delivery is a precondition for advanced realtime communications service delivery.. Aka ubiquitous video calling. Would that be a reasonable presumption? From: Date: Thursday, June 11, 2015 at 9:02 AM To: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. Richard, For a number of years, there has been an optional caller name dispay featur= e attached to some of the telephone services in France, but indeed nothing like the standalone CNAM service concept that underpins the discussions on this list. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Richard Shockey Date :11/06/2015 05:21 (GMT+01:00) =C0 : Brian Rosen , Henning Schulzrinne Cc : cnit@ietf.org=20 Objet : Re: [cnit] CNIT Charter bashing.. Here is what I want to know now. Before we start to process this concept I want to know how relevant the existing CNAM service is deployed outside North America. I=B9m told by reliable sources that the CNAM service is not deployed anywhere among the major telecom markets in Europe or Asia. Not Japan China or South Korea UK Italy France and in fact it might actually be illegal under the strict privacy regulations in Germany. I don=B9t know.=20 That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would b= e responsible for defining how the VoLTE CUA could actually display an advanced call display data and frankly no one knows. http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= - 6 There is a realistic question if this is simply a North American specific problem why is this a IETF issue. You might ask the same question of MODER= N but I frankly don=B9t want to go there. From: Richard Shockey Date: Tuesday, June 2, 2015 at 12:35 PM To: Brian Rosen Cc: Subject: Re: [cnit] CNIT Charter bashing.. Hopefully but I still haven=B9t seen any response to my concern about normative dependencies on STIR. If we can define the object/headers first then I don=B9t have a issue. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey Cc: Eric Burger , Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian > On May 28, 2015, at 1:55 PM, Richard Shockey wrote: >=20 >=20 > A fair argument but I don=B9t want to spend 5 years waiting for a series of > normative dependencies on the trust model before actually understanding w= hat > headers can/should be used here. >=20 >=20 > Its much too difficult to get things done in the IETF as it is. I=B9d muc= h > prefer building from success starting with the definition of the data obj= ect > then ..then folding that into a trust model and frankly given what we hav= e > seen in STIR I=B9m not sure your argument holds up. Again the MARTINI model= . >=20 > Didn=B9t you recently say something about =B3perfection is the enemy of the = good=B2 > :-)=20 >=20 >=20 >=20 > From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM > To: > Subject: Re: [cnit] CNIT Charter bashing.. >=20 > On May 25, 2015, at 5:31 PM, Richard Shockey wrote: >>=20 >> From: Mary Barnes >> Date: Friday, May 22, 2015 at 12:58 PM >> Attached is what I have at this point. Really, the only thing I'm strugg= ling >> with is the milestones as I don't think we can request publication of th= e >> data object and headers without having defined the trust model. >>=20 >>=20 >> RS> Mary I=B9m not sure about that statement. I can certainly anticipate >> several deployment models where the trust mechanism (aka signing) does n= ot >> need to be formally integrated in the solution especially those where th= e >> exchange of data is more bi-lateral and the trust mechanism is at lower >> layers of the stack than the signaling. My initial concern is what is t= he >> header and what is the data object(s) carried in the header. How the CNI= T >> data is created should not be our concern. >=20 > I do not buy it. If there are private agreements between service provider= s, > they have private agreements. They can do whatever they want. >=20 > Last I looked, this is the Internet Engineering Task Force. Assume untrus= ted > transport across the wide open Internet, and trust no endpoint that canno= t > cryptographically prove who they are. If it happens two service providers > exchange CNIT data over a single, yellow cable, then it is a benefit that= no > state-sponsored security service can listen in on the cable. >=20 > I do not want to take three years to build a protocol and two more years = after > that for products to be available just to have a system that only works i= n > walled gardens. I do not want to be the person that has to explain to the > media why Calling Name Delivery is just as broken as it always was and it= will > be another five years before the world sees a real solution. >=20 > Let us get this right the first time. > [snip] > _______________________________________________ cnit mailing list > cnit@ietf.orghttps://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 ___________________________________________________________________________= _ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit --B_3516867971_78554 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

Thank you that is very helpful. I’m assuming its network deliv= ered based on information derived from the calling party billing data.
=

My other running assumption has been that some form Adva= nced Calling Name Delivery is a precondition for advanced realtime communica= tions service delivery.. Aka ubiquitous video calling.   Would that be = a reasonable presumption?

Fr= om: <philippe.fouqu= art@orange.com>
Date: Thurs= day, June 11, 2015 at 9:02 AM
To: = "cnit@ietf.org" <cnit@ietf.org>
Subject: <= /span> Re: [cnit] CNIT Charter bashing..

Richard,

Fo= r a number of years, there has been an optional caller name dispay feature a= ttached to some of the telephone services in France, but indeed nothing like= the standalone CNAM service concept that underpins the discussions on this = list.

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13


-------- Message d'origine -= -------
De : Richard Shockey
Date :11/06/2015 05:21 (GM= T+01:00)
=C0 : Brian Rosen , Henning Schulzrinne
Cc : cnit@ietf.org
Objet : Re: [cnit]= CNIT Charter bashing..


<= div>

Here is what I want to know now.

Before we start to process this concept I want to kn= ow how relevant the existing CNAM service is deployed outside North America.=

I’m told by reliable sources that the CNAM s= ervice is not deployed anywhere among the major telecom markets in Europe or= Asia. Not Japan China or South Korea UK Italy France and in fact it might a= ctually be illegal under the strict privacy regulations in Germany.

I don’t know. 
<= br>
That said our friends at Apple seem to understand there is a p= roblem here. I have tried to engage the most senior management at Google abo= ut who would be responsible for defining how the VoLTE CUA could actually di= splay an advanced call display data and frankly no one knows. 

There is a realistic question if t= his is simply a North American specific problem why is this  a IETF iss= ue. You might ask the same question of MODERN but I frankly don’t want= to go there.




From: Richard Shockey <richard@shockey.us>
Date: Tuesday, June 2, 2015 at 12:35 PM
To: Brian Rosen <br@brian= rosen.net>
Cc: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

=

Hopefully but I s= till haven’t seen any response to my concern about normative dependenc= ies on STIR.

If we can define the object/headers fi= rst then I don’t have a issue.

—&n= bsp;
Richard Shockey
Shockey Consulting LLC
Ch= airman of the Board SIP Forum
www.shockey.us
www.sipforu= m.org
richard<at>shockey.us
Skype-Linkedin-Faceboo= k rshockey101
PSTN +1 703-593-2683


From: Brian Rosen <br@brianrosen.net>
Date: Tuesday, June 2, 2015 at 12:26 PM
To: Richard Shockey <richard@shockey.us>
Cc: <= /span>Eric Burger <eburger@st= andardstrack.com>, <cnit@ietf.org>
Subject: Re: [cnit] CNIT Cha= rter bashing..

Are we planning to submit a charter in the next couple of days, a= nd then see if we can get a slot at the next IETF?

Brian
On May 28, 2015, at 1:55 PM, Richa= rd Shockey <richard@shockey.= us> wrote:

<= div class=3D"" style=3D"word-wrap:break-word; font-size:14px; font-family:Calibr= i,sans-serif">

<= div class=3D"">A fair argument but I don’t want to spend 5 years waiting= for a series of normative dependencies on the trust model before actually u= nderstanding what headers can/should be used here. 
=

Its much t= oo difficult to get things done in the IETF as it is.   I’d much = prefer building from success starting with the definition of the data object= then ..then folding that into a trust model and frankly given what we have = seen in STIR I’m not sure your argument holds up. Again the MARTINI model.

Didn’t you recently  say some= thing about “perfection is the enemy of the good”  :-) = ;



From: Eric Burger <eburger@standardstrack.com>
Date: Wednesday, May= 27, 2015 at 10:11 PM
To= : <cnit@ietf.org>Subject: Re: [cnit= ] CNIT Charter bashing..

=
On May 25, 2015, at= 5:31 PM, Richard Shockey <r= ichard@shockey.us> wrote:

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Friday, May 22, 2015 at 12:58 PM
Attached is what I have at this poi= nt. Really, the only thing I'm struggling with is the milestones as I don't = think we can request publication of the data object and headers without havi= ng defined the trust model. 


RS> Mary I’m not = sure about that statement. I can certainly anticipate several deployment mod= els where the trust mechanism (aka signing) does not need to be formally int= egrated in the solution especially those where the exchange of data is more bi-lateral and the trust mechanism is at lower layers of the stack than th= e signaling. My initial concern  is what is the header and what is the = data object(s) carried in the header. How the CNIT data is created should no= t be our concern.

<= /div> I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want.

Last I looked, this is the&n= bsp;Internet Engineering Task Force. Assume untrusted t= ransport across the wide open Internet, and trust no endpoint that cannot cr= yptographically prove who they are. If it happens two service providers exch= ange CNIT data over a single, yellow cable, then it is a benefit that no state-= sponsored security service can listen in on the cable.
I do not want to take three years to build a = protocol and two more years after that for products to be available just to = have a system that only works in walled gardens. I do not want to be the per= son that has to explain to the media why Calling Name Delivery is just as broken as it always was and it will be another fi= ve years before the world sees a real solution.

Let us get this right the first time.
[snip]
_______________________________________________ cnit mailing list cnit@ietf.orghttps://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 http= s://www.ietf.org/mailman/listinfo/cnit
________________=
____________________________________________________________________________=
_____________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/m= ailman/listinfo/cnit --B_3516867971_78554-- From nobody Thu Jun 11 09:18:54 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF091B307D for ; Thu, 11 Jun 2015 09:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7EAD5tAJloa for ; Thu, 11 Jun 2015 09:18:46 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675AA1B307E for ; Thu, 11 Jun 2015 09:18:45 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 4e4b9755.0.447994.00-2190.1266213.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 11 Jun 2015 16:18:45 +0000 (UTC) X-MXL-Hash: 5579b4e52f47bc1a-048558b8caca37553213dea67daf5a02c0e9e0e6 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5BGIhaD004903; Thu, 11 Jun 2015 12:18:43 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5BGIXfB004755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jun 2015 12:18:39 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 11 Jun 2015 16:18:30 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.218]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0224.002; Thu, 11 Jun 2015 12:18:30 -0400 From: "DOLLY, MARTIN C" To: Richard Shockey , "philippe.fouquart@orange.com" , "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27d4mIgS3m+kqeJkvhgMQzyp2ne2iA Date: Thu, 11 Jun 2015 16:18:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.170.154] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365603614617MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=b4YFFK6x c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=57hriNzNDrAA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAA] X-AnalysisOut: [AA:8 a=OTLVf7z5AAAA:8 a=HLLxP2VMAAAA:8 a=ll-iCDY8AAAA:8 a=] X-AnalysisOut: [M0OflfRGAAAA:8 a=bfLuiRfvAAAA:8 a=pGLkceISAAAA:8 a=dHBqEyD] X-AnalysisOut: [EEUTGOAxu_mAA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpO] X-AnalysisOut: [X-4qs7AA:10 a=BQYh4w-RC7EA:10 a=h7FFQaHNOm0A:10 a=-FEs8UIg] X-AnalysisOut: [K8oA:10 a=NWVoK91CQyQA:10 a=_oJPKDn-z3YAzHUJ:21 a=YSi81wIT] X-AnalysisOut: [ehkPLyWp:21 a=lZlPz1uII3pmmdqXmwIA:9 a=UiCQ7L4-1S4A:10 a=h] X-AnalysisOut: [TZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=8MOA3] X-AnalysisOut: [R60bSAhZ8oz:21 a=nTtqq406ZnqQLaGk:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:18:53 -0000 --_000_E42CCDDA6722744CB241677169E8365603614617MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I got a different answer from the Orange/FT folks at the CT WG meetings....= .so please check and clarify.... From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, June 11, 2015 11:46 AM To: philippe.fouquart@orange.com; cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. Thank you that is very helpful. I'm assuming its network delivered based on= information derived from the calling party billing data. My other running assumption has been that some form Advanced Calling Name D= elivery is a precondition for advanced realtime communications service deli= very.. Aka ubiquitous video calling. Would that be a reasonable presumpti= on? From: > Date: Thursday, June 11, 2015 at 9:02 AM To: "cnit@ietf.org" > Subject: Re: [cnit] CNIT Charter bashing.. Richard, For a number of years, there has been an optional caller name dispay featur= e attached to some of the telephone services in France, but indeed nothing = like the standalone CNAM service concept that underpins the discussions on = this list. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Richard Shockey Date :11/06/2015 05:21 (GMT+01:00) =C0 : Brian Rosen , Henning Schulzrinne Cc : cnit@ietf.org Objet : Re: [cnit] CNIT Charter bashing.. Here is what I want to know now. Before we start to process this concept I want to know how relevant the exi= sting CNAM service is deployed outside North America. I'm told by reliable sources that the CNAM service is not deployed anywhere= among the major telecom markets in Europe or Asia. Not Japan China or Sout= h Korea UK Italy France and in fact it might actually be illegal under the = strict privacy regulations in Germany. I don't know. That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would= be responsible for defining how the VoLTE CUA could actually display an ad= vanced call display data and frankly no one knows. http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= -6 There is a realistic question if this is simply a North American specific p= roblem why is this a IETF issue. You might ask the same question of MODERN= but I frankly don't want to go there. From: Richard Shockey > Date: Tuesday, June 2, 2015 at 12:35 PM To: Brian Rosen > Cc: > Subject: Re: [cnit] CNIT Charter bashing.. Hopefully but I still haven't seen any response to my concern about normati= ve dependencies on STIR. If we can define the object/headers first then I don't have a issue. - Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen > Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey > Cc: Eric Burger >, > Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian On May 28, 2015, at 1:55 PM, Richard Shockey > wrote: A fair argument but I don't want to spend 5 years waiting for a series of n= ormative dependencies on the trust model before actually understanding what= headers can/should be used here. Its much too difficult to get things done in the IETF as it is. I'd much = prefer building from success starting with the definition of the data objec= t then ..then folding that into a trust model and frankly given what we hav= e seen in STIR I'm not sure your argument holds up. Again the MARTINI model= . Didn't you recently say something about "perfection is the enemy of the go= od" :-) From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM To: > Subject: Re: [cnit] CNIT Charter bashing.. On May 25, 2015, at 5:31 PM, Richard Shockey > wrote: From: Mary Barnes > Date: Friday, May 22, 2015 at 12:58 PM Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the= data object and headers without having defined the trust model. RS> Mary I'm not sure about that statement. I can certainly anticipate seve= ral deployment models where the trust mechanism (aka signing) does not need= to be formally integrated in the solution especially those where the excha= nge of data is more bi-lateral and the trust mechanism is at lower layers o= f the stack than the signaling. My initial concern is what is the header a= nd what is the data object(s) carried in the header. How the CNIT data is c= reated should not be our concern. I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want. Last I looked, this is the Internet Engineering Task Force. Assume untruste= d transport across the wide open Internet, and trust no endpoint that canno= t cryptographically prove who they are. If it happens two service providers= exchange CNIT data over a single, yellow cable, then it is a benefit that = no state-sponsored security service can listen in on the cable. I do not want to take three years to build a protocol and two more years af= ter that for products to be available just to have a system that only works= in walled gardens. I do not want to be the person that has to explain to t= he media why Calling Name Delivery is just as broken as it always was and i= t will be another five years before the world sees a real solution. Let us get this right the first time. [snip] _______________________________________________ cnit mailing list cnit@ietf= .orghttps://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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ cnit mailing list cnit@ietf= .org https://www.ietf.org/mailman/listinfo/cnit --_000_E42CCDDA6722744CB241677169E8365603614617MISOUT7MSGUSRDB_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I got a different answer from the Ora= nge/FT folks at the CT WG meetings…..so please check and clarify̷= 0;.

 

From: cnit [mailto:cnit-bounces@ietf= .org] On Behalf Of Richard Shockey
Sent: Thursday, June 11, 2015 11:46 AM
To: philippe.fouquart@orange.com; cnit@ietf.org
Subject: Re: [cnit] CNIT Charter bashing..

 

 

Thank you that is very helpful. I’= ;m assuming its network delivered based on information derived from the cal= ling party billing data.

 

My other running assumption has been th= at some form Advanced Calling Name Delivery is a precondition for advanced = realtime communications service delivery.. Aka ubiquitous video calling.   Would that be a reasonable presumption?

 

From: <philippe.fouquart@orange.com>
Date: Thursday, June 11, 2015 at 9:02 AM
To: "cnit@ietf.org" &= lt;cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

Richard,

 

For a number of years, there has been a= n optional caller name dispay feature attached to some of the telephone ser= vices in France, but indeed nothing like the standalone CNAM service concept that underpins the discussions on this list.

 

Regards,

 

Philip= pe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

&nb= sp;

-------- Message d'origine --------

De : Richard Shockey

Date :11/06/2015 05:21 (GMT+01:00)

=C0 : Brian Rosen , Henning Schulzrinne

Objet : Re: [cnit] CNIT Charter bashing= ..

 

 

 

Here is what I want to know now.

 

Before we start to process this concept= I want to know how relevant the existing CNAM service is deployed outside = North America.

 

I’m told by reliable sources that= the CNAM service is not deployed anywhere among the major telecom markets = in Europe or Asia. Not Japan China or South Korea UK Italy France and in fact it might actually be illegal under the strict pri= vacy regulations in Germany.

 

I don’t know. 

 

That said our friends at Apple seem to = understand there is a problem here. I have tried to engage the most senior = management at Google about who would be responsible for defining how the VoLTE CUA could actually display an advanced call dis= play data and frankly no one knows. 

 

 

There is a realistic question if this is simply a North Ameri= can specific problem why is this  a IETF issue. You might ask the same= question of MODERN but I frankly don’t want to go there.

 

 

 

 

From: Richard Shockey <richard@shockey.us>
Date: Tuesday, June 2, 2015 at 12:35 PM
To: Brian Rosen <br@brianros= en.net>
Cc: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

 

Hopefully but I still haven’t see= n any response to my concern about normative dependencies on STIR.

 

If we can define the object/headers fir= st then I don’t have a issue.

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

richard<at>shockey.us<= /span>

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

 

 

From: Brian Rosen <br@brianrosen.net>
Date: Tuesday, June 2, 2015 at 12:26 PM
To: Richard Shockey <richar= d@shockey.us>
Cc: Eric Burger <eb= urger@standardstrack.com>, <cnit= @ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

Are we planning to submit a charter in = the next couple of days, and then see if we can get a slot at the next IETF= ?

 

Brian

On May 28, 2015, at 1:55 PM, Richard Sh= ockey <richard@shockey.us> = wrote:

 

 

A fair argument but I don’t want = to spend 5 years waiting for a series of normative dependencies on the trus= t model before actually understanding what headers can/should be used here. 

 

 

Its much too difficult to get things do= ne in the IETF as it is.   I’d much prefer building from success= starting with the definition of the data object then ..then folding that into a trust model and frankly given what we have seen in STI= R I’m not sure your argument holds up. Again the MARTINI model.<= /o:p>

 

Didn’t you recently  say som= ething about “perfection is the enemy of the good”  :-)&nb= sp;

 

 

 

From: Eric Burger <eburger@standardstrack.com>
Date: Wednesday, May 27, 2015 at 10:11 PM
To: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

On May 25, 2015, at 5:31 PM, Richard Sh= ockey <richard@shockey.us> = wrote:

 

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Friday, May 22, 2015 at 12:58 PM

Attached is what I have at this point. = Really, the only thing I'm struggling with is the milestones as I don't thi= nk we can request publication of the data object and headers without having defined the trust model. 

 

 

RS> Mary I’m not sure about th= at statement. I can certainly anticipate several deployment models where th= e trust mechanism (aka signing) does not need to be formally integrated in the solution especially those where the exchange of data is = more bi-lateral and the trust mechanism is at lower layers of the stack tha= n the signaling. My initial concern  is what is the header and what is= the data object(s) carried in the header. How the CNIT data is created should not be our concern.<= /p>

 

I do not buy it. If there are private a= greements between service providers, they have private agreements. They can= do whatever they want.

 

Last I looked, this is the Inte= rnet Engineering Task Force. Assume untrusted transport across the= wide open Internet, and trust no endpoint that cannot cryptographically prove who they are. If it happens two service providers exchange CNIT data= over a single, yellow cable, then it is a benefit that no state-sponsored = security service can listen in on the cable.

 

I do not want to take three years to bu= ild a protocol and two more years after that for products to be available j= ust to have a system that only works in walled gardens. I do not want to be the person that has to explain to the media w= hy Calling Name Delivery is just as broken as it always was and it will be = another five years before the world sees a real solution.=

 

Let us get this right the first time.

[snip]

_______________________________________= ________ cnit mailing list cnit@ietf.orghttps://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

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.

_______________________________________= ________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit

--_000_E42CCDDA6722744CB241677169E8365603614617MISOUT7MSGUSRDB_-- From nobody Thu Jun 11 10:08:12 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA9B1B32E6 for ; Thu, 11 Jun 2015 10:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGQ5-UK5MSdG for ; Thu, 11 Jun 2015 10:08:09 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3CE1B29CD for ; Thu, 11 Jun 2015 10:08:08 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , "philippe.fouquart@orange.com" , "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752niJBh Date: Thu, 11 Jun 2015 17:08:07 +0000 References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 17:08:12 -0000 The topic of caller name delivery came up (along with STIR and other topics= ) at a recent event: http://www.aging.senate.gov/hearings/ringing-off-the-hook_examining-the-pro= liferation-of-unwanted-calls CNIT is making a cameo appearance as well. I would summarize the event as "= bipartisan frustration with the status quo". ________________________________ From: cnit [cnit-bounces@ietf.org] on behalf of Richard Shockey [richard@sh= ockey.us] Sent: Thursday, June 11, 2015 11:46 AM To: philippe.fouquart@orange.com; cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. Thank you that is very helpful. I=92m assuming its network delivered based = on information derived from the calling party billing data. My other running assumption has been that some form Advanced Calling Name D= elivery is a precondition for advanced realtime communications service deli= very.. Aka ubiquitous video calling. Would that be a reasonable presumpti= on? From: > Date: Thursday, June 11, 2015 at 9:02 AM To: "cnit@ietf.org" > Subject: Re: [cnit] CNIT Charter bashing.. Richard, For a number of years, there has been an optional caller name dispay featur= e attached to some of the telephone services in France, but indeed nothing = like the standalone CNAM service concept that underpins the discussions on = this list. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Richard Shockey Date :11/06/2015 05:21 (GMT+01:00) =C0 : Brian Rosen , Henning Schulzrinne Cc : cnit@ietf.org Objet : Re: [cnit] CNIT Charter bashing.. Here is what I want to know now. Before we start to process this concept I want to know how relevant the exi= sting CNAM service is deployed outside North America. I=92m told by reliable sources that the CNAM service is not deployed anywhe= re among the major telecom markets in Europe or Asia. Not Japan China or So= uth Korea UK Italy France and in fact it might actually be illegal under th= e strict privacy regulations in Germany. I don=92t know. That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would= be responsible for defining how the VoLTE CUA could actually display an ad= vanced call display data and frankly no one knows. http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= -6 There is a realistic question if this is simply a North American specific p= roblem why is this a IETF issue. You might ask the same question of MODERN= but I frankly don=92t want to go there. From: Richard Shockey > Date: Tuesday, June 2, 2015 at 12:35 PM To: Brian Rosen > Cc: > Subject: Re: [cnit] CNIT Charter bashing.. Hopefully but I still haven=92t seen any response to my concern about norma= tive dependencies on STIR. If we can define the object/headers first then I don=92t have a issue. =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen > Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey > Cc: Eric Burger >, > Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian On May 28, 2015, at 1:55 PM, Richard Shockey > wrote: A fair argument but I don=92t want to spend 5 years waiting for a series of= normative dependencies on the trust model before actually understanding wh= at headers can/should be used here. Its much too difficult to get things done in the IETF as it is. I=92d muc= h prefer building from success starting with the definition of the data obj= ect then ..then folding that into a trust model and frankly given what we h= ave seen in STIR I=92m not sure your argument holds up. Again the MARTINI m= odel. Didn=92t you recently say something about =93perfection is the enemy of th= e good=94 :-) From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM To: > Subject: Re: [cnit] CNIT Charter bashing.. On May 25, 2015, at 5:31 PM, Richard Shockey > wrote: From: Mary Barnes > Date: Friday, May 22, 2015 at 12:58 PM Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the= data object and headers without having defined the trust model. RS> Mary I=92m not sure about that statement. I can certainly anticipate se= veral deployment models where the trust mechanism (aka signing) does not ne= ed to be formally integrated in the solution especially those where the exc= hange of data is more bi-lateral and the trust mechanism is at lower layers= of the stack than the signaling. My initial concern is what is the header= and what is the data object(s) carried in the header. How the CNIT data is= created should not be our concern. I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want. Last I looked, this is the Internet Engineering Task Force. Assume untruste= d transport across the wide open Internet, and trust no endpoint that canno= t cryptographically prove who they are. If it happens two service providers= exchange CNIT data over a single, yellow cable, then it is a benefit that = no state-sponsored security service can listen in on the cable. I do not want to take three years to build a protocol and two more years af= ter that for products to be available just to have a system that only works= in walled gardens. I do not want to be the person that has to explain to t= he media why Calling Name Delivery is just as broken as it always was and i= t will be another five years before the world sees a real solution. Let us get this right the first time. [snip] _______________________________________________ cnit mailing list cnit@ietf= .orghttps://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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ cnit mailing list cnit@ietf= .org https://www.ietf.org/mailman/listinfo/cnit From nobody Thu Jun 11 11:00:22 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83661AD0C0 for ; Thu, 11 Jun 2015 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfMtsXEr5Q7O for ; Thu, 11 Jun 2015 11:00:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BD71ACDD2 for ; Thu, 11 Jun 2015 11:00:15 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C5A0622CD96; Thu, 11 Jun 2015 20:00:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.13]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A4C2E238048; Thu, 11 Jun 2015 20:00:13 +0200 (CEST) Received: from OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0235.001; Thu, 11 Jun 2015 20:00:13 +0200 From: To: "DOLLY, MARTIN C" , Richard Shockey , "cnit@ietf.org" Thread-Topic: RE : [cnit] CNIT Charter bashing.. Thread-Index: AQHQpHB2y/ydkg4NN0q2ZZlkT63NMg== Date: Thu, 11 Jun 2015 18:00:13 +0000 Message-ID: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_fki5dyxdmgyv92b6hugpfuoy1434045608655emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.2.75418 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 18:00:21 -0000 --_000_fki5dyxdmgyv92b6hugpfuoy1434045608655emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The feature I was referring to http://assistance.orange.fr/presentation-du-nom-de-la-ligne-fixe-utilisatio= n-4010.php (In French, with my apologies) As I said, it isn't a CNAM service. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : "DOLLY, MARTIN C" Date :11/06/2015 18:18 (GMT+01:00) =C0 : Richard Shockey , FOUQUART Philippe IMT/OLN , cnit@ietf.org Objet : RE: [cnit] CNIT Charter bashing.. I got a different answer from the Orange/FT folks at the CT WG meetings=85.= .so please check and clarify=85. From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, June 11, 2015 11:46 AM To: philippe.fouquart@orange.com; cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. Thank you that is very helpful. I=92m assuming its network delivered based = on information derived from the calling party billing data. My other running assumption has been that some form Advanced Calling Name D= elivery is a precondition for advanced realtime communications service deli= very.. Aka ubiquitous video calling. Would that be a reasonable presumpti= on? From: > Date: Thursday, June 11, 2015 at 9:02 AM To: "cnit@ietf.org" > Subject: Re: [cnit] CNIT Charter bashing.. Richard, For a number of years, there has been an optional caller name dispay featur= e attached to some of the telephone services in France, but indeed nothing = like the standalone CNAM service concept that underpins the discussions on = this list. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Richard Shockey Date :11/06/2015 05:21 (GMT+01:00) =C0 : Brian Rosen , Henning Schulzrinne Cc : cnit@ietf.org Objet : Re: [cnit] CNIT Charter bashing.. Here is what I want to know now. Before we start to process this concept I want to know how relevant the exi= sting CNAM service is deployed outside North America. I=92m told by reliable sources that the CNAM service is not deployed anywhe= re among the major telecom markets in Europe or Asia. Not Japan China or So= uth Korea UK Italy France and in fact it might actually be illegal under th= e strict privacy regulations in Germany. I don=92t know. That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would= be responsible for defining how the VoLTE CUA could actually display an ad= vanced call display data and frankly no one knows. http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= -6 There is a realistic question if this is simply a North American specific p= roblem why is this a IETF issue. You might ask the same question of MODERN= but I frankly don=92t want to go there. From: Richard Shockey > Date: Tuesday, June 2, 2015 at 12:35 PM To: Brian Rosen > Cc: > Subject: Re: [cnit] CNIT Charter bashing.. Hopefully but I still haven=92t seen any response to my concern about norma= tive dependencies on STIR. If we can define the object/headers first then I don=92t have a issue. =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen > Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey > Cc: Eric Burger >, > Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian On May 28, 2015, at 1:55 PM, Richard Shockey > wrote: A fair argument but I don=92t want to spend 5 years waiting for a series of= normative dependencies on the trust model before actually understanding wh= at headers can/should be used here. Its much too difficult to get things done in the IETF as it is. I=92d muc= h prefer building from success starting with the definition of the data obj= ect then ..then folding that into a trust model and frankly given what we h= ave seen in STIR I=92m not sure your argument holds up. Again the MARTINI m= odel. Didn=92t you recently say something about =93perfection is the enemy of th= e good=94 :-) From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM To: > Subject: Re: [cnit] CNIT Charter bashing.. On May 25, 2015, at 5:31 PM, Richard Shockey > wrote: From: Mary Barnes > Date: Friday, May 22, 2015 at 12:58 PM Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the= data object and headers without having defined the trust model. RS> Mary I=92m not sure about that statement. I can certainly anticipate se= veral deployment models where the trust mechanism (aka signing) does not ne= ed to be formally integrated in the solution especially those where the exc= hange of data is more bi-lateral and the trust mechanism is at lower layers= of the stack than the signaling. My initial concern is what is the header= and what is the data object(s) carried in the header. How the CNIT data is= created should not be our concern. I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want. Last I looked, this is the Internet Engineering Task Force. Assume untruste= d transport across the wide open Internet, and trust no endpoint that canno= t cryptographically prove who they are. If it happens two service providers= exchange CNIT data over a single, yellow cable, then it is a benefit that = no state-sponsored security service can listen in on the cable. I do not want to take three years to build a protocol and two more years af= ter that for products to be available just to have a system that only works= in walled gardens. I do not want to be the person that has to explain to t= he media why Calling Name Delivery is just as broken as it always was and i= t will be another five years before the world sees a real solution. Let us get this right the first time. [snip] _______________________________________________ cnit mailing list cnit@ietf= .orghttps://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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ cnit mailing list cnit@ietf= .org https://www.ietf.org/mailman/listinfo/cnit ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_fki5dyxdmgyv92b6hugpfuoy1434045608655emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The feature I was referring to
http://assistance.orange.fr/presentation-du-nom-de-la-ligne-fixe-utili= sation-4010.php 
(In French, with my apologies)
As I said, it isn't a CNAM service. 

Regards,

Philippe Fouquart
Orange Labs Networks<= span class=3D"Apple-style-span" style=3D"color:rgb(31,73,125); font-family:= Arial; font-size:13.333333015441895px">
+33 (0) 1 45 29 58 13


-------- Message d'origine --------
De : "DOLLY, MARTIN C"
Date :11/06/2015 18:18 (GMT+01:00)
=C0 : Richard Shockey , FOUQUART Philippe IMT/OLN , cnit@ietf.org
Objet : RE: [cnit] CNIT Charter bashing..

I got a different answer from the O= range/FT folks at the CT WG meetings=85..so please check and clarify=85.

 

From: cnit [mailto:cnit-bounces@ie= tf.org] On Behalf Of Richard Shockey
Sent: Thursday, June 11, 2015 11:46 AM
To: philippe.fouquart@orange.com; cnit@ietf.org
Subject: Re: [cnit] CNIT Charter bashing..

 

 

Thank you that is very helpful. I=92m= assuming its network delivered based on information derived from the calli= ng party billing data.

 

My other running assumption has been = that some form Advanced Calling Name Delivery is a precondition for advance= d realtime communications service delivery.. Aka ubiquitous video calling.   Would that be a reasonable presumption?

 

From: <philippe.fouquart@orange.com>
Date: Thursday, June 11, 2015 at 9:02 AM
To: "cnit@ietf.org" &= lt;cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

Richard,

 

For a number of years, there has been= an optional caller name dispay feature attached to some of the telephone s= ervices in France, but indeed nothing like the standalone CNAM service concept that underpins the discussions on this lis= t.

 

Regards,

 

Phil= ippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

 =

-------- Message d'origine --------

De : Richard Shockey

Date :11/06/2015 05:21 (GMT+01:00)

=C0 : Brian Rosen , Henning Schulzrin= ne

Objet : Re: [cnit] CNIT Charter bashi= ng..

 

 

 

Here is what I want to know now.

 

Before we start to process this conce= pt I want to know how relevant the existing CNAM service is deployed outsid= e North America.

 

I=92m told by reliable sources that t= he CNAM service is not deployed anywhere among the major telecom markets in= Europe or Asia. Not Japan China or South Korea UK Italy France and in fact it might actually be illegal under the strict = privacy regulations in Germany.

 

I don=92t know. 

 

That said our friends at Apple seem t= o understand there is a problem here. I have tried to engage the most senio= r management at Google about who would be responsible for defining how the VoLTE CUA could actually display an advanced call dis= play data and frankly no one knows. 

 

 

There is a realistic question if this is simply a North Ame= rican specific problem why is this  a IETF issue. You might ask the sa= me question of MODERN but I frankly don=92t want to go there.

 

 

 

 

From: Richard Shockey <richard@shockey.us>
Date: Tuesday, June 2, 2015 at 12:35 PM
To: Brian Rosen <br@brianros= en.net>
Cc: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

 

Hopefully but I still haven=92t seen = any response to my concern about normative dependencies on STIR.

 

If we can define the object/headers f= irst then I don=92t have a issue.

 

=97 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

 

 

From: Brian Rosen <br@brianrosen.net>
Date: Tuesday, June 2, 2015 at 12:26 PM
To: Richard Shockey <richar= d@shockey.us>
Cc: Eric Burger <eb= urger@standardstrack.com>, <cnit= @ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

Are we planning to submit a charter i= n the next couple of days, and then see if we can get a slot at the next IE= TF?

 

Brian

On May 28, 2015, at 1:55 PM, Richard = Shockey <richard@shockey.us>= ; wrote:

 

 

A fair argument but I don=92t want to= spend 5 years waiting for a series of normative dependencies on the trust = model before actually understanding what headers can/should be used here. 

 

 

Its much too difficult to get things = done in the IETF as it is.   I=92d much prefer building from success s= tarting with the definition of the data object then ..then folding that into a trust model and frankly given what we have seen in STI= R I=92m not sure your argument holds up. Again the MARTINI model.

 

Didn=92t you recently  say somet= hing about =93perfection is the enemy of the good=94  :-) =

 

 

 

From: Eric Burger <eburger@standardstrack.com>
Date: Wednesday, May 27, 2015 at 10:11 PM
To: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

 

On May 25, 2015, at 5:31 PM, Richard = Shockey <richard@shockey.us>= ; wrote:

 

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Friday, May 22, 2015 at 12:58 PM

Attached is what I have at this point= . Really, the only thing I'm struggling with is the milestones as I don't t= hink we can request publication of the data object and headers without having defined the trust model. 

 

 

RS> Mary I=92m not sure about that= statement. I can certainly anticipate several deployment models where the = trust mechanism (aka signing) does not need to be formally integrated in the solution especially those where the exchange of data is = more bi-lateral and the trust mechanism is at lower layers of the stack tha= n the signaling. My initial concern  is what is the header and what is= the data object(s) carried in the header. How the CNIT data is created should not be our concern.

 

I do not buy it. If there are private= agreements between service providers, they have private agreements. They c= an do whatever they want.

 

Last I looked, this is the In= ternet Engineering Task Force. Assume untrusted transport across t= he wide open Internet, and trust no endpoint that cannot cryptographically prove who they are. If it happens two service providers = exchange CNIT data over a single, yellow cable, then it is a benefit that n= o state-sponsored security service can listen in on the cable.

 

I do not want to take three years to = build a protocol and two more years after that for products to be available= just to have a system that only works in walled gardens. I do not want to be the person that has to explain to the media w= hy Calling Name Delivery is just as broken as it always was and it will be = another five years before the world sees a real solution.

 

Let us get this right the first time.=

[snip]

_____________________________________= __________ cnit mailing list cnit@ietf.orghttps://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

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.

Thank you.

_____________________________________= __________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_fki5dyxdmgyv92b6hugpfuoy1434045608655emailandroidcom_-- From nobody Thu Jun 11 11:05:31 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA64D1A9136 for ; Thu, 11 Jun 2015 11:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huYloMBW-Ufu for ; Thu, 11 Jun 2015 11:05:15 -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 363E41A8AA8 for ; Thu, 11 Jun 2015 11:05:15 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "philippe.fouquart@orange.com" , "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z5w== Date: Thu, 11 Jun 2015 18:05:14 +0000 References: , , <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> In-Reply-To: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 18:05:27 -0000 >From my reading, the function seems similar to caller name delivery, even i= f the mechanism is not a CNAM database. According to Google Translate: Presented coordinates are those listed in the directories. These are necess= arily the coordinates of the line holder that are displayed. The name of th= e calling line holder is displayed only if the call is presented on a compa= tible device. ________________________________ From: cnit [cnit-bounces@ietf.org] on behalf of philippe.fouquart@orange.co= m [philippe.fouquart@orange.com] Sent: Thursday, June 11, 2015 2:00 PM To: DOLLY, MARTIN C; Richard Shockey; cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. The feature I was referring to http://assistance.orange.fr/presentation-du-nom-de-la-ligne-fixe-utilisatio= n-4010.php (In French, with my apologies) As I said, it isn't a CNAM service. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : "DOLLY, MARTIN C" Date :11/06/2015 18:18 (GMT+01:00) =C0 : Richard Shockey , FOUQUART Philippe IMT/OLN , cnit@ietf.org Objet : RE: [cnit] CNIT Charter bashing.. I got a different answer from the Orange/FT folks at the CT WG meetings=85.= .so please check and clarify=85. From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, June 11, 2015 11:46 AM To: philippe.fouquart@orange.com; cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. Thank you that is very helpful. I=92m assuming its network delivered based = on information derived from the calling party billing data. My other running assumption has been that some form Advanced Calling Name D= elivery is a precondition for advanced realtime communications service deli= very.. Aka ubiquitous video calling. Would that be a reasonable presumpti= on? From: > Date: Thursday, June 11, 2015 at 9:02 AM To: "cnit@ietf.org" > Subject: Re: [cnit] CNIT Charter bashing.. Richard, For a number of years, there has been an optional caller name dispay featur= e attached to some of the telephone services in France, but indeed nothing = like the standalone CNAM service concept that underpins the discussions on = this list. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Richard Shockey Date :11/06/2015 05:21 (GMT+01:00) =C0 : Brian Rosen , Henning Schulzrinne Cc : cnit@ietf.org Objet : Re: [cnit] CNIT Charter bashing.. Here is what I want to know now. Before we start to process this concept I want to know how relevant the exi= sting CNAM service is deployed outside North America. I=92m told by reliable sources that the CNAM service is not deployed anywhe= re among the major telecom markets in Europe or Asia. Not Japan China or So= uth Korea UK Italy France and in fact it might actually be illegal under th= e strict privacy regulations in Germany. I don=92t know. That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would= be responsible for defining how the VoLTE CUA could actually display an ad= vanced call display data and frankly no one knows. http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= -6 There is a realistic question if this is simply a North American specific p= roblem why is this a IETF issue. You might ask the same question of MODERN= but I frankly don=92t want to go there. From: Richard Shockey > Date: Tuesday, June 2, 2015 at 12:35 PM To: Brian Rosen > Cc: > Subject: Re: [cnit] CNIT Charter bashing.. Hopefully but I still haven=92t seen any response to my concern about norma= tive dependencies on STIR. If we can define the object/headers first then I don=92t have a issue. =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen > Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey > Cc: Eric Burger >, > Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian On May 28, 2015, at 1:55 PM, Richard Shockey > wrote: A fair argument but I don=92t want to spend 5 years waiting for a series of= normative dependencies on the trust model before actually understanding wh= at headers can/should be used here. Its much too difficult to get things done in the IETF as it is. I=92d muc= h prefer building from success starting with the definition of the data obj= ect then ..then folding that into a trust model and frankly given what we h= ave seen in STIR I=92m not sure your argument holds up. Again the MARTINI m= odel. Didn=92t you recently say something about =93perfection is the enemy of th= e good=94 :-) From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM To: > Subject: Re: [cnit] CNIT Charter bashing.. On May 25, 2015, at 5:31 PM, Richard Shockey > wrote: From: Mary Barnes > Date: Friday, May 22, 2015 at 12:58 PM Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the= data object and headers without having defined the trust model. RS> Mary I=92m not sure about that statement. I can certainly anticipate se= veral deployment models where the trust mechanism (aka signing) does not ne= ed to be formally integrated in the solution especially those where the exc= hange of data is more bi-lateral and the trust mechanism is at lower layers= of the stack than the signaling. My initial concern is what is the header= and what is the data object(s) carried in the header. How the CNIT data is= created should not be our concern. I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want. Last I looked, this is the Internet Engineering Task Force. Assume untruste= d transport across the wide open Internet, and trust no endpoint that canno= t cryptographically prove who they are. If it happens two service providers= exchange CNIT data over a single, yellow cable, then it is a benefit that = no state-sponsored security service can listen in on the cable. I do not want to take three years to build a protocol and two more years af= ter that for products to be available just to have a system that only works= in walled gardens. I do not want to be the person that has to explain to t= he media why Calling Name Delivery is just as broken as it always was and i= t will be another five years before the world sees a real solution. Let us get this right the first time. [snip] _______________________________________________ cnit mailing list cnit@ietf= .orghttps://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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ cnit mailing list cnit@ietf= .org https://www.ietf.org/mailman/listinfo/cnit ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jun 11 12:58:09 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6741B311C for ; Thu, 11 Jun 2015 12:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UWeq5tA-QGO for ; Thu, 11 Jun 2015 12:58:06 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 9E68E1B3118 for ; Thu, 11 Jun 2015 12:58:06 -0700 (PDT) Received: (qmail 14289 invoked by uid 0); 11 Jun 2015 19:58:04 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy5.mail.unifiedlayer.com with SMTP; 11 Jun 2015 19:58:04 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id f7WS1q00C1MNPNq017WVuq; Thu, 11 Jun 2015 13:30:29 -0600 X-Authority-Analysis: v=2.1 cv=cooIzTIi c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=wUoZ4loKAAAA:8 a=VfRrSUvcAAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=OTLVf7z5AAAA:8 a=HLLxP2VMAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=bfLuiRfvAAAA:8 a=pGLkceISAAAA:8 a=SNb6eOulMZ17R4FZVesA:9 a=vzdJRCpSxRMZRzon:21 a=sSdJzcKzkUASdKiP:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=cJ9POpqApfoSRSmN82wiTVQ9XpvtQUXpItI4e2srobs=; b=etTh0EHlymEepkS2uOjwVGX7qhC7T9N8Db2cop78pn38wKIKH+e6KMEaHNlPzJ5sXc+7z2UrrYsaYKB1evFZeSu3fVFd05HOH1w21KI4ZZpSZA2zejUio9QPwgpprRSW; Received: from [108.56.131.149] (port=59654 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z38Ib-0007q6-DT; Thu, 11 Jun 2015 13:38:01 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Thu, 11 Jun 2015 15:37:57 -0400 From: Richard Shockey To: Henning Schulzrinne , "philippe.fouquart@orange.com" , "cnit@ietf.org" Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 19:58:08 -0000 On 6/11/15, 1:08 PM, "Henning Schulzrinne" wrote: >The topic of caller name delivery came up (along with STIR and other >topics) at a recent event: > >http://www.aging.senate.gov/hearings/ringing-off-the-hook_examining-the-pr >oliferation-of-unwanted-calls > >CNIT is making a cameo appearance as well. I would summarize the event as >"bipartisan frustration with the status quo". Yep =8A =20 http://thehill.com/policy/technology/244566-senators-pile-on-the-robocall-b ashing > >________________________________ >From: cnit [cnit-bounces@ietf.org] on behalf of Richard Shockey >[richard@shockey.us] >Sent: Thursday, June 11, 2015 11:46 AM >To: philippe.fouquart@orange.com; cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > > >Thank you that is very helpful. I=B9m assuming its network delivered based >on information derived from the calling party billing data. > >My other running assumption has been that some form Advanced Calling Name >Delivery is a precondition for advanced realtime communications service >delivery.. Aka ubiquitous video calling. Would that be a reasonable >presumption? > >From: > >Date: Thursday, June 11, 2015 at 9:02 AM >To: "cnit@ietf.org" >> >Subject: Re: [cnit] CNIT Charter bashing.. > >Richard, > >For a number of years, there has been an optional caller name dispay >feature attached to some of the telephone services in France, but indeed >nothing like the standalone CNAM service concept that underpins the >discussions on this list. > >Regards, > >Philippe Fouquart >Orange Labs Networks >+33 (0) 1 45 29 58 13 > > >-------- Message d'origine -------- >De : Richard Shockey >Date :11/06/2015 05:21 (GMT+01:00) >=C0 : Brian Rosen , Henning Schulzrinne >Cc : cnit@ietf.org >Objet : Re: [cnit] CNIT Charter bashing.. > > > >Here is what I want to know now. > >Before we start to process this concept I want to know how relevant the >existing CNAM service is deployed outside North America. > >I=B9m told by reliable sources that the CNAM service is not deployed >anywhere among the major telecom markets in Europe or Asia. Not Japan >China or South Korea UK Italy France and in fact it might actually be >illegal under the strict privacy regulations in Germany. > >I don=B9t know. > >That said our friends at Apple seem to understand there is a problem >here. I have tried to engage the most senior management at Google about >who would be responsible for defining how the VoLTE CUA could actually >display an advanced call display data and frankly no one knows. > >http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-201 >5-6 > >There is a realistic question if this is simply a North American specific >problem why is this a IETF issue. You might ask the same question of >MODERN but I frankly don=B9t want to go there. > > > > >From: Richard Shockey > >Date: Tuesday, June 2, 2015 at 12:35 PM >To: Brian Rosen > >Cc: > >Subject: Re: [cnit] CNIT Charter bashing.. > > >Hopefully but I still haven=B9t seen any response to my concern about >normative dependencies on STIR. > >If we can define the object/headers first then I don=B9t have a issue. > >=8B >Richard Shockey >Shockey Consulting LLC >Chairman of the Board SIP Forum >www.shockey.us >www.sipforum.org >richardshockey.us >Skype-Linkedin-Facebook rshockey101 >PSTN +1 703-593-2683 > > >From: Brian Rosen > >Date: Tuesday, June 2, 2015 at 12:26 PM >To: Richard Shockey > >Cc: Eric Burger=20 >>, >> >Subject: Re: [cnit] CNIT Charter bashing.. > >Are we planning to submit a charter in the next couple of days, and then >see if we can get a slot at the next IETF? > >Brian >On May 28, 2015, at 1:55 PM, Richard Shockey >> wrote: > > >A fair argument but I don=B9t want to spend 5 years waiting for a series of >normative dependencies on the trust model before actually understanding >what headers can/should be used here. > > >Its much too difficult to get things done in the IETF as it is. I=B9d >much prefer building from success starting with the definition of the >data object then ..then folding that into a trust model and frankly given >what we have seen in STIR I=B9m not sure your argument holds up. Again the >MARTINI model. > >Didn=B9t you recently say something about =B3perfection is the enemy of the >good=B2 :-) > > > >From: Eric Burger=20 >> >Date: Wednesday, May 27, 2015 at 10:11 PM >To: > >Subject: Re: [cnit] CNIT Charter bashing.. > >On May 25, 2015, at 5:31 PM, Richard Shockey >> wrote: > >From: Mary Barnes=20 >> >Date: Friday, May 22, 2015 at 12:58 PM >Attached is what I have at this point. Really, the only thing I'm >struggling with is the milestones as I don't think we can request >publication of the data object and headers without having defined the >trust model. > > >RS> Mary I=B9m not sure about that statement. I can certainly anticipate >several deployment models where the trust mechanism (aka signing) does >not need to be formally integrated in the solution especially those where >the exchange of data is more bi-lateral and the trust mechanism is at >lower layers of the stack than the signaling. My initial concern is what >is the header and what is the data object(s) carried in the header. How >the CNIT data is created should not be our concern. > >I do not buy it. If there are private agreements between service >providers, they have private agreements. They can do whatever they want. > >Last I looked, this is the Internet Engineering Task Force. Assume >untrusted transport across the wide open Internet, and trust no endpoint >that cannot cryptographically prove who they are. If it happens two >service providers exchange CNIT data over a single, yellow cable, then it >is a benefit that no state-sponsored security service can listen in on >the cable. > >I do not want to take three years to build a protocol and two more years >after that for products to be available just to have a system that only >works in walled gardens. I do not want to be the person that has to >explain to the media why Calling Name Delivery is just as broken as it >always was and it will be another five years before the world sees a real >solution. > >Let us get this right the first time. >[snip] >_______________________________________________ cnit mailing list >cnit@ietf.orghttps://www.ietf.org/mailman/listinfo/c >nit >_______________________________________________ >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 > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > > >_______________________________________________ cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit From nobody Fri Jun 12 03:15:28 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DFF1A9069 for ; Fri, 12 Jun 2015 03:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJLGLgbLl2Vd for ; Fri, 12 Jun 2015 03:15:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD951A9048 for ; Fri, 12 Jun 2015 03:11:54 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C9C0A32424A for ; Fri, 12 Jun 2015 12:11:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.42]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A4703238074 for ; Fri, 12 Jun 2015 12:11:52 +0200 (CEST) Received: from OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0235.001; Fri, 12 Jun 2015 12:11:52 +0200 From: To: "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27iFN1WQzWX0CDYxORzklKjZ2nWj6AgAAcbYCAAAFmAIABIZXw Date: Fri, 12 Jun 2015 10:11:52 +0000 Message-ID: <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> References: , , <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.12.93315 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 10:15:27 -0000 As far as what the feature does, I think you are right. And after all, disp= laying a name is..., well just that really, displaying a name and the varia= tions are mostly around whether the source is authoritative or to what exte= nt.=20=20 As to the misunderstanding relative to whether this is or isn't implemented= , I know that this hasn't been massively successful as a feature and the ne= ed to replicate that beyond TDM isn't clear. It would seem that most people= would consider at this stage that "matching-CLI-with-names-in-Contacts-and= -displaying-the-CLI-or-anonymous-when-not-present" is just good enough. Dis= playing names was a challenge in environments and days when contact books w= eren't available and although from an engineering perspective, not having a= single format to display may not be satisfactory or ideal for both CgP and= CdP, it may actually be a de facto happy medium for their conflicting need= s for privacy/information respectively. Probably slightly off topic for th= is list.=20=20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Message d'origine----- De=A0: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Envoy=E9=A0: jeudi 11 juin 2015 20:05 =C0=A0: FOUQUART Philippe IMT/OLN; cnit@ietf.org Objet=A0: RE: [cnit] CNIT Charter bashing.. >From my reading, the function seems similar to caller name delivery, even i= f the mechanism is not a CNAM database. According to Google Translate: Presented coordinates are those listed in the directories. These are necess= arily the coordinates of the line holder that are displayed. The name of th= e calling line holder is displayed only if the call is presented on a compa= tible device. ________________________________ From: cnit [cnit-bounces@ietf.org] on behalf of philippe.fouquart@orange.co= m [philippe.fouquart@orange.com] Sent: Thursday, June 11, 2015 2:00 PM To: DOLLY, MARTIN C; Richard Shockey; cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. The feature I was referring to http://assistance.orange.fr/presentation-du-nom-de-la-ligne-fixe-utilisatio= n-4010.php (In French, with my apologies) As I said, it isn't a CNAM service. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : "DOLLY, MARTIN C" Date :11/06/2015 18:18 (GMT+01:00) =C0 : Richard Shockey , FOUQUART Philippe IMT/OLN , cnit@ietf.org Objet : R= E: [cnit] CNIT Charter bashing.. I got a different answer from the Orange/FT folks at the CT WG meetings...s= o please check and clarify.. From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, June 11, 2015 11:46 AM To: philippe.fouquart@orange.com; cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. Thank you that is very helpful. I'm assuming its network delivered based on= information derived from the calling party billing data. My other running assumption has been that some form Advanced Calling Name D= elivery is a precondition for advanced realtime communications service deli= very.. Aka ubiquitous video calling. Would that be a reasonable presumpti= on? From: > Date: Thursday, June 11, 2015 at 9:02 AM To: "cnit@ietf.org" > Subject: Re: [cnit] CNIT Charter bashing.. Richard, For a number of years, there has been an optional caller name dispay featur= e attached to some of the telephone services in France, but indeed nothing = like the standalone CNAM service concept that underpins the discussions on = this list. Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Richard Shockey Date :11/06/2015 05:21 (GMT+01:00) =C0 : Brian Rosen , Henning Schulzrinne Cc : cnit@ietf.org Objet : Re: [cnit] CNIT Charter bashing.. Here is what I want to know now. Before we start to process this concept I want to know how relevant the exi= sting CNAM service is deployed outside North America. I'm told by reliable sources that the CNAM service is not deployed anywhere= among the major telecom markets in Europe or Asia. Not Japan China or Sout= h Korea UK Italy France and in fact it might actually be illegal under the = strict privacy regulations in Germany. I don't know. That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would= be responsible for defining how the VoLTE CUA could actually display an ad= vanced call display data and frankly no one knows. http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= -6 There is a realistic question if this is simply a North American specific p= roblem why is this a IETF issue. You might ask the same question of MODERN= but I frankly don't want to go there. From: Richard Shockey > Date: Tuesday, June 2, 2015 at 12:35 PM To: Brian Rosen > Cc: > Subject: Re: [cnit] CNIT Charter bashing.. Hopefully but I still haven't seen any response to my concern about normati= ve dependencies on STIR. If we can define the object/headers first then I don't have a issue. - Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen > Date: Tuesday, June 2, 2015 at 12:26 PM To: Richard Shockey > Cc: Eric Burger >, > Subject: Re: [cnit] CNIT Charter bashing.. Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF? Brian On May 28, 2015, at 1:55 PM, Richard Shockey > wrote: A fair argument but I don't want to spend 5 years waiting for a series of n= ormative dependencies on the trust model before actually understanding what= headers can/should be used here. Its much too difficult to get things done in the IETF as it is. I'd much = prefer building from success starting with the definition of the data objec= t then ..then folding that into a trust model and frankly given what we hav= e seen in STIR I'm not sure your argument holds up. Again the MARTINI model. Didn't you recently say something about "perfection is the enemy of the go= od" :-) From: Eric Burger > Date: Wednesday, May 27, 2015 at 10:11 PM To: > Subject: Re: [cnit] CNIT Charter bashing.. On May 25, 2015, at 5:31 PM, Richard Shockey > wrote: From: Mary Barnes > Date: Friday, May 22, 2015 at 12:58 PM Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the= data object and headers without having defined the trust model. RS> Mary I'm not sure about that statement. I can certainly anticipate seve= ral deployment models where the trust mechanism (aka signing) does not need= to be formally integrated in the solution especially those where the excha= nge of data is more bi-lateral and the trust mechanism is at lower layers o= f the stack than the signaling. My initial concern is what is the header a= nd what is the data object(s) carried in the header. How the CNIT data is c= reated should not be our concern. I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want. Last I looked, this is the Internet Engineering Task Force. Assume untruste= d transport across the wide open Internet, and trust no endpoint that canno= t cryptographically prove who they are. If it happens two service providers= exchange CNIT data over a single, yellow cable, then it is a benefit that = no state-sponsored security service can listen in on the cable. I do not want to take three years to build a protocol and two more years af= ter that for products to be available just to have a system that only works= in walled gardens. I do not want to be the person that has to explain to t= he media why Calling Name Delivery is just as broken as it always was and i= t will be another five years before the world sees a real solution. Let us get this right the first time. [snip] _______________________________________________ cnit mailing list cnit@ietf= .orghttps://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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ cnit mailing list cnit@ietf= .org https://www.ietf.org/mailman/listinfo/cnit ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jun 12 06:13:32 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6111A9235 for ; Fri, 12 Jun 2015 06:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yc5cuOUBb2e for ; Fri, 12 Jun 2015 06:13:26 -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 8B4271A9234 for ; Fri, 12 Jun 2015 06:13:25 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "philippe.fouquart@orange.com" , "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEA///tFM0= Date: Fri, 12 Jun 2015 13:13:24 +0000 References: , , <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> , <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> In-Reply-To: <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> 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 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 13:13:30 -0000 >From what I can tell, North American businesses see a fair amount of value = in this feature, as many people (due to robocalls) won't pick up anonymous = calls or calls from numbers they do not recognize. In addition, this addres= s book has to be created somehow. It's a whole lot easier to auto-populate = the name from the caller name information than asking users to type in the = name for the person that just called them. After all, that's how typical em= ail-derived address books work - people don't type in that information.=0A= =0A= I suspect we'll see, as in the Apple announcement, various third-party klud= ges that go beyond the personal address book, where Google and Apple (and, = with a year or two delay, Microsoft) try to use their own data, web page da= ta and maybe crowd-sourced data to create a pseudo-CNAM, with a proprietary= architecture and opaque data sources. This will work ok to the point where= a business finds that their name is horribly mangled and then tries to det= ermine how they can get it fixed by somebody they can't talk to.=0A= =0A= That said, we're talking about a SIP feature (display name) that already ex= ists and is, I assume, widely used for enterprise VoIP systems. Thus, my go= al is modest: allow signed and extended versions of the display name. =0A= =0A= I find it peculiar that carriers always say that they want to be more than = bit pipes, but then find all kinds of reasons not to add value to their ser= vices. This obviously only applies to people and organizations not on this = list :-)=0A= =0A= Henning=0A= =0A= =0A= ________________________________________=0A= From: cnit [cnit-bounces@ietf.org] on behalf of philippe.fouquart@orange.co= m [philippe.fouquart@orange.com]=0A= Sent: Friday, June 12, 2015 6:11 AM=0A= To: cnit@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= As far as what the feature does, I think you are right. And after all, disp= laying a name is..., well just that really, displaying a name and the varia= tions are mostly around whether the source is authoritative or to what exte= nt.=0A= =0A= As to the misunderstanding relative to whether this is or isn't implemented= , I know that this hasn't been massively successful as a feature and the ne= ed to replicate that beyond TDM isn't clear. It would seem that most people= would consider at this stage that "matching-CLI-with-names-in-Contacts-and= -displaying-the-CLI-or-anonymous-when-not-present" is just good enough. Dis= playing names was a challenge in environments and days when contact books w= eren't available and although from an engineering perspective, not having a= single format to display may not be satisfactory or ideal for both CgP and= CdP, it may actually be a de facto happy medium for their conflicting need= s for privacy/information respectively. Probably slightly off topic for th= is list.=0A= =0A= Philippe Fouquart=0A= Orange Labs Networks=0A= +33 (0) 1 45 29 58 13=0A= =0A= -----Message d'origine-----=0A= De : Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=0A= Envoy=E9 : jeudi 11 juin 2015 20:05=0A= =C0 : FOUQUART Philippe IMT/OLN; cnit@ietf.org=0A= Objet : RE: [cnit] CNIT Charter bashing..=0A= =0A= >From my reading, the function seems similar to caller name delivery, even = if the mechanism is not a CNAM database.=0A= =0A= According to Google Translate:=0A= =0A= Presented coordinates are those listed in the directories. These are necess= arily the coordinates of the line holder that are displayed. The name of th= e calling line holder is displayed only if the call is presented on a compa= tible device.=0A= =0A= ________________________________=0A= From: cnit [cnit-bounces@ietf.org] on behalf of philippe.fouquart@orange.co= m [philippe.fouquart@orange.com]=0A= Sent: Thursday, June 11, 2015 2:00 PM=0A= To: DOLLY, MARTIN C; Richard Shockey; cnit@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= The feature I was referring to=0A= http://assistance.orange.fr/presentation-du-nom-de-la-ligne-fixe-utilisatio= n-4010.php=0A= (In French, with my apologies)=0A= As I said, it isn't a CNAM service.=0A= =0A= Regards,=0A= =0A= Philippe Fouquart=0A= Orange Labs Networks=0A= +33 (0) 1 45 29 58 13=0A= =0A= =0A= -------- Message d'origine --------=0A= De : "DOLLY, MARTIN C"=0A= Date :11/06/2015 18:18 (GMT+01:00)=0A= =C0 : Richard Shockey , FOUQUART Philippe IMT/OLN , cnit@ietf.org Objet : R= E: [cnit] CNIT Charter bashing..=0A= =0A= I got a different answer from the Orange/FT folks at the CT WG meetings...s= o please check and clarify..=0A= =0A= From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey=0A= Sent: Thursday, June 11, 2015 11:46 AM=0A= To: philippe.fouquart@orange.com; cnit@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= =0A= Thank you that is very helpful. I'm assuming its network delivered based on= information derived from the calling party billing data.=0A= =0A= My other running assumption has been that some form Advanced Calling Name D= elivery is a precondition for advanced realtime communications service deli= very.. Aka ubiquitous video calling. Would that be a reasonable presumpti= on?=0A= =0A= From: >= =0A= Date: Thursday, June 11, 2015 at 9:02 AM=0A= To: "cnit@ietf.org" >=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= Richard,=0A= =0A= For a number of years, there has been an optional caller name dispay featur= e attached to some of the telephone services in France, but indeed nothing = like the standalone CNAM service concept that underpins the discussions on = this list.=0A= =0A= Regards,=0A= =0A= Philippe Fouquart=0A= Orange Labs Networks=0A= +33 (0) 1 45 29 58 13=0A= =0A= -------- Message d'origine --------=0A= De : Richard Shockey=0A= Date :11/06/2015 05:21 (GMT+01:00)=0A= =C0 : Brian Rosen , Henning Schulzrinne=0A= Cc : cnit@ietf.org=0A= Objet : Re: [cnit] CNIT Charter bashing..=0A= =0A= =0A= =0A= Here is what I want to know now.=0A= =0A= Before we start to process this concept I want to know how relevant the exi= sting CNAM service is deployed outside North America.=0A= =0A= I'm told by reliable sources that the CNAM service is not deployed anywhere= among the major telecom markets in Europe or Asia. Not Japan China or Sout= h Korea UK Italy France and in fact it might actually be illegal under the = strict privacy regulations in Germany.=0A= =0A= I don't know.=0A= =0A= That said our friends at Apple seem to understand there is a problem here. = I have tried to engage the most senior management at Google about who would= be responsible for defining how the VoLTE CUA could actually display an ad= vanced call display data and frankly no one knows.=0A= =0A= http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015= -6=0A= =0A= There is a realistic question if this is simply a North American specific p= roblem why is this a IETF issue. You might ask the same question of MODERN= but I frankly don't want to go there.=0A= =0A= =0A= =0A= =0A= From: Richard Shockey >=0A= Date: Tuesday, June 2, 2015 at 12:35 PM=0A= To: Brian Rosen >=0A= Cc: >=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= =0A= Hopefully but I still haven't seen any response to my concern about normati= ve dependencies on STIR.=0A= =0A= If we can define the object/headers first then I don't have a issue.=0A= =0A= -=0A= Richard Shockey=0A= Shockey Consulting LLC=0A= Chairman of the Board SIP Forum=0A= www.shockey.us=0A= www.sipforum.org=0A= richardshockey.us=0A= Skype-Linkedin-Facebook rshockey101=0A= PSTN +1 703-593-2683=0A= =0A= =0A= From: Brian Rosen >=0A= Date: Tuesday, June 2, 2015 at 12:26 PM=0A= To: Richard Shockey >=0A= Cc: Eric Burger >, >=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= Are we planning to submit a charter in the next couple of days, and then se= e if we can get a slot at the next IETF?=0A= =0A= Brian=0A= On May 28, 2015, at 1:55 PM, Richard Shockey > wrote:=0A= =0A= =0A= A fair argument but I don't want to spend 5 years waiting for a series of n= ormative dependencies on the trust model before actually understanding what= headers can/should be used here.=0A= =0A= =0A= Its much too difficult to get things done in the IETF as it is. I'd much = prefer building from success starting with the definition of the data objec= t then ..then folding that into a trust model and frankly given what we hav= e seen in STIR I'm not sure your argument holds up. Again the MARTINI model= .=0A= =0A= Didn't you recently say something about "perfection is the enemy of the go= od" :-)=0A= =0A= =0A= =0A= From: Eric Burger >=0A= Date: Wednesday, May 27, 2015 at 10:11 PM=0A= To: >=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= On May 25, 2015, at 5:31 PM, Richard Shockey > wrote:=0A= =0A= From: Mary Barnes >=0A= Date: Friday, May 22, 2015 at 12:58 PM=0A= Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the= data object and headers without having defined the trust model.=0A= =0A= =0A= RS> Mary I'm not sure about that statement. I can certainly anticipate seve= ral deployment models where the trust mechanism (aka signing) does not need= to be formally integrated in the solution especially those where the excha= nge of data is more bi-lateral and the trust mechanism is at lower layers o= f the stack than the signaling. My initial concern is what is the header a= nd what is the data object(s) carried in the header. How the CNIT data is c= reated should not be our concern.=0A= =0A= I do not buy it. If there are private agreements between service providers,= they have private agreements. They can do whatever they want.=0A= =0A= Last I looked, this is the Internet Engineering Task Force. Assume untruste= d transport across the wide open Internet, and trust no endpoint that canno= t cryptographically prove who they are. If it happens two service providers= exchange CNIT data over a single, yellow cable, then it is a benefit that = no state-sponsored security service can listen in on the cable.=0A= =0A= I do not want to take three years to build a protocol and two more years af= ter that for products to be available just to have a system that only works= in walled gardens. I do not want to be the person that has to explain to t= he media why Calling Name Delivery is just as broken as it always was and i= t will be another five years before the world sees a real solution.=0A= =0A= Let us get this right the first time.=0A= [snip]=0A= _______________________________________________ cnit mailing list cnit@ietf= .orghttps://www.ietf.org/mailman/listinfo/cnit=0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= _______________________________________________ cnit mailing list cnit@ietf= .org https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= ___________________________________________________________________________= ______________________________________________=0A= =0A= =0A= =0A= Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc=0A= =0A= pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler=0A= =0A= a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,=0A= =0A= Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.=0A= =0A= =0A= =0A= This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;=0A= =0A= they should not be distributed, used or copied without authorisation.=0A= =0A= If you have received this email in error, please notify the sender and dele= te this message and its attachments.=0A= =0A= As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.=0A= =0A= Thank you.=0A= _______________________________________________ cnit mailing list cnit@ietf= .org https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= ___________________________________________________________________________= ______________________________________________=0A= =0A= Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.= =0A= =0A= This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation.=0A= If you have received this email in error, please notify the sender and dele= te this message and its attachments.=0A= As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.=0A= Thank you.=0A= =0A= =0A= ___________________________________________________________________________= ______________________________________________=0A= =0A= Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc=0A= pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler=0A= a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,=0A= Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.=0A= =0A= This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;=0A= they should not be distributed, used or copied without authorisation.=0A= If you have received this email in error, please notify the sender and dele= te this message and its attachments.=0A= As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.=0A= Thank you.=0A= =0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= From nobody Fri Jun 12 06:56:55 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E24E1AC3FC for ; Fri, 12 Jun 2015 06:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob8EjfGCccN9 for ; Fri, 12 Jun 2015 06:56:50 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 9DBDA1AC3FB for ; Fri, 12 Jun 2015 06:56:50 -0700 (PDT) Received: (qmail 1918 invoked by uid 0); 12 Jun 2015 13:56:49 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy4.mail.unifiedlayer.com with SMTP; 12 Jun 2015 13:56:49 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id fXVu1q00V1MNPNq01XVxpS; Fri, 12 Jun 2015 13:29:57 -0600 X-Authority-Analysis: v=2.1 cv=K/SxQUmI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=jKZ029TlAAAA:8 a=OTLVf7z5AAAA:8 a=HLLxP2VMAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=bfLuiRfvAAAA:8 a=pGLkceISAAAA:8 a=OjAO0AJQm2TZWLKD68oA:9 a=OisW1ap6CBkzvXjq:21 a=AlxJrouqeSJf2MKd:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=+iQc1dU8EBe0VQC3MMbExqh3IAiAmVsFDIxQjkfogPk=; b=YCbAm9Uz0gdbg4XLygjT4EAKglklAm/R1mozHaPqs/V0keZoStCeKBvo3+m9/DDSrl7nCPQw5oSyJam4C2Ccmg9qJvAVQ2BvI5sve5/EbE2rQTEe+HvrxLLQGBToALPu; Received: from [108.56.131.149] (port=49328 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z3P8X-0003Wf-Nj; Fri, 12 Jun 2015 07:36:46 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Fri, 12 Jun 2015 09:36:39 -0400 From: Richard Shockey To: Henning Schulzrinne , "philippe.fouquart@orange.com" , "cnit@ietf.org" Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 13:56:54 -0000 In line On 6/12/15, 9:13 AM, "Henning Schulzrinne" wrote: >>From what I can tell, North American businesses see a fair amount of >>value in this feature, as many people (due to robocalls) won't pick up >>anonymous calls or calls from numbers they do not recognize. In >>addition, this address book has to be created somehow. It's a whole lot >>easier to auto-populate the name from the caller name information than >>asking users to type in the name for the person that just called them. >>After all, that's how typical email-derived address books work - people >>don't type in that information. > >I suspect we'll see, as in the Apple announcement, various third-party >kludges that go beyond the personal address book, where Google and Apple >(and, with a year or two delay, Microsoft) try to use their own data, web >page data and maybe crowd-sourced data to create a pseudo-CNAM, with a >proprietary architecture and opaque data sources. This will work ok to >the point where a business finds that their name is horribly mangled and >then tries to determine how they can get it fixed by somebody they can't >talk to. RS> Amen .. > >That said, we're talking about a SIP feature (display name) that already >exists and is, I assume, widely used for enterprise VoIP systems. Thus, >my goal is modest: allow signed and extended versions of the display name. RS> Well intra enterprise certainly. There it tends to get pulled from Active Directory but until we can get the NNI interface deployed its not working at all for inter enterprise. We are certainly looking at that for Phase 2 of the NNI TF. My goal is some what more modest for a first phase. Certainly you want signed extended versions of the display name but one should not create artificial barriers to non signed data exchanges between service providers where the security comes from the big yellow wire at Layer 1. Plus I still want a straight answer if this proposal is going to have a requirement for a new SIP header and all the IETF ART pain and suffering that goes with that. I want the AD=B9s to make that demand ( if it is to be imposed) explicit now. >=20 > >I find it peculiar that carriers always say that they want to be more >than bit pipes, but then find all kinds of reasons not to add value to >their services. This obviously only applies to people and organizations >not on this list :-) =20 > >Henning > > >________________________________________ >From: cnit [cnit-bounces@ietf.org] on behalf of >philippe.fouquart@orange.com [philippe.fouquart@orange.com] >Sent: Friday, June 12, 2015 6:11 AM >To: cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > >As far as what the feature does, I think you are right. And after all, >displaying a name is..., well just that really, displaying a name and the >variations are mostly around whether the source is authoritative or to >what extent. > >As to the misunderstanding relative to whether this is or isn't >implemented, I know that this hasn't been massively successful as a >feature and the need to replicate that beyond TDM isn't clear. It would >seem that most people would consider at this stage that >"matching-CLI-with-names-in-Contacts-and-displaying-the-CLI-or-anonymous-w >hen-not-present" is just good enough. Displaying names was a challenge in >environments and days when contact books weren't available and although >from an engineering perspective, not having a single format to display >may not be satisfactory or ideal for both CgP and CdP, it may actually be >a de facto happy medium for their conflicting needs for >privacy/information respectively. Probably slightly off topic for this >list. > >Philippe Fouquart >Orange Labs Networks >+33 (0) 1 45 29 58 13 > >-----Message d'origine----- >De : Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >Envoy=E9 : jeudi 11 juin 2015 20:05 >=C0 : FOUQUART Philippe IMT/OLN; cnit@ietf.org >Objet : RE: [cnit] CNIT Charter bashing.. > >>From my reading, the function seems similar to caller name delivery, >>even if the mechanism is not a CNAM database. > >According to Google Translate: > >Presented coordinates are those listed in the directories. These are >necessarily the coordinates of the line holder that are displayed. The >name of the calling line holder is displayed only if the call is >presented on a compatible device. > >________________________________ >From: cnit [cnit-bounces@ietf.org] on behalf of >philippe.fouquart@orange.com [philippe.fouquart@orange.com] >Sent: Thursday, June 11, 2015 2:00 PM >To: DOLLY, MARTIN C; Richard Shockey; cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > >The feature I was referring to >http://assistance.orange.fr/presentation-du-nom-de-la-ligne-fixe-utilisati >on-4010.php >(In French, with my apologies) >As I said, it isn't a CNAM service. > >Regards, > >Philippe Fouquart >Orange Labs Networks >+33 (0) 1 45 29 58 13 > > >-------- Message d'origine -------- >De : "DOLLY, MARTIN C" >Date :11/06/2015 18:18 (GMT+01:00) >=C0 : Richard Shockey , FOUQUART Philippe IMT/OLN , cnit@ietf.org Objet : >RE: [cnit] CNIT Charter bashing.. > >I got a different answer from the Orange/FT folks at the CT WG >meetings...so please check and clarify.. > >From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey >Sent: Thursday, June 11, 2015 11:46 AM >To: philippe.fouquart@orange.com; cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > > >Thank you that is very helpful. I'm assuming its network delivered based >on information derived from the calling party billing data. > >My other running assumption has been that some form Advanced Calling Name >Delivery is a precondition for advanced realtime communications service >delivery.. Aka ubiquitous video calling. Would that be a reasonable >presumption? > >From: > >Date: Thursday, June 11, 2015 at 9:02 AM >To: "cnit@ietf.org" >> >Subject: Re: [cnit] CNIT Charter bashing.. > >Richard, > >For a number of years, there has been an optional caller name dispay >feature attached to some of the telephone services in France, but indeed >nothing like the standalone CNAM service concept that underpins the >discussions on this list. > >Regards, > >Philippe Fouquart >Orange Labs Networks >+33 (0) 1 45 29 58 13 > >-------- Message d'origine -------- >De : Richard Shockey >Date :11/06/2015 05:21 (GMT+01:00) >=C0 : Brian Rosen , Henning Schulzrinne >Cc : cnit@ietf.org >Objet : Re: [cnit] CNIT Charter bashing.. > > > >Here is what I want to know now. > >Before we start to process this concept I want to know how relevant the >existing CNAM service is deployed outside North America. > >I'm told by reliable sources that the CNAM service is not deployed >anywhere among the major telecom markets in Europe or Asia. Not Japan >China or South Korea UK Italy France and in fact it might actually be >illegal under the strict privacy regulations in Germany. > >I don't know. > >That said our friends at Apple seem to understand there is a problem >here. I have tried to engage the most senior management at Google about >who would be responsible for defining how the VoLTE CUA could actually >display an advanced call display data and frankly no one knows. > >http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-201 >5-6 > >There is a realistic question if this is simply a North American specific >problem why is this a IETF issue. You might ask the same question of >MODERN but I frankly don't want to go there. > > > > >From: Richard Shockey > >Date: Tuesday, June 2, 2015 at 12:35 PM >To: Brian Rosen > >Cc: > >Subject: Re: [cnit] CNIT Charter bashing.. > > >Hopefully but I still haven't seen any response to my concern about >normative dependencies on STIR. > >If we can define the object/headers first then I don't have a issue. > >- >Richard Shockey >Shockey Consulting LLC >Chairman of the Board SIP Forum >www.shockey.us >www.sipforum.org >richardshockey.us >Skype-Linkedin-Facebook rshockey101 >PSTN +1 703-593-2683 > > >From: Brian Rosen > >Date: Tuesday, June 2, 2015 at 12:26 PM >To: Richard Shockey > >Cc: Eric Burger=20 >>, >> >Subject: Re: [cnit] CNIT Charter bashing.. > >Are we planning to submit a charter in the next couple of days, and then >see if we can get a slot at the next IETF? > >Brian >On May 28, 2015, at 1:55 PM, Richard Shockey >> wrote: > > >A fair argument but I don't want to spend 5 years waiting for a series of >normative dependencies on the trust model before actually understanding >what headers can/should be used here. > > >Its much too difficult to get things done in the IETF as it is. I'd >much prefer building from success starting with the definition of the >data object then ..then folding that into a trust model and frankly given >what we have seen in STIR I'm not sure your argument holds up. Again the >MARTINI model. > >Didn't you recently say something about "perfection is the enemy of the >good" :-) > > > >From: Eric Burger=20 >> >Date: Wednesday, May 27, 2015 at 10:11 PM >To: > >Subject: Re: [cnit] CNIT Charter bashing.. > >On May 25, 2015, at 5:31 PM, Richard Shockey >> wrote: > >From: Mary Barnes=20 >> >Date: Friday, May 22, 2015 at 12:58 PM >Attached is what I have at this point. Really, the only thing I'm >struggling with is the milestones as I don't think we can request >publication of the data object and headers without having defined the >trust model. > > >RS> Mary I'm not sure about that statement. I can certainly anticipate >several deployment models where the trust mechanism (aka signing) does >not need to be formally integrated in the solution especially those where >the exchange of data is more bi-lateral and the trust mechanism is at >lower layers of the stack than the signaling. My initial concern is what >is the header and what is the data object(s) carried in the header. How >the CNIT data is created should not be our concern. > >I do not buy it. If there are private agreements between service >providers, they have private agreements. They can do whatever they want. > >Last I looked, this is the Internet Engineering Task Force. Assume >untrusted transport across the wide open Internet, and trust no endpoint >that cannot cryptographically prove who they are. If it happens two >service providers exchange CNIT data over a single, yellow cable, then it >is a benefit that no state-sponsored security service can listen in on >the cable. > >I do not want to take three years to build a protocol and two more years >after that for products to be available just to have a system that only >works in walled gardens. I do not want to be the person that has to >explain to the media why Calling Name Delivery is just as broken as it >always was and it will be another five years before the world sees a real >solution. > >Let us get this right the first time. >[snip] >_______________________________________________ cnit mailing list >cnit@ietf.orghttps://www.ietf.org/mailman/listinfo/c >nit >_______________________________________________ >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 > >__________________________________________________________________________ >_______________________________________________ > > > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc > >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler > >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, > >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > > > >This message and its attachments may contain confidential or privileged >information that may be protected by law; > >they should not be distributed, used or copied without authorisation. > >If you have received this email in error, please notify the sender and >delete this message and its attachments. > >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. > >Thank you. >_______________________________________________ cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >exploites ou copies sans autorisation. Si vous avez recu ce message par >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les >pieces jointes. Les messages electroniques etant susceptibles >d'alteration, Orange decline toute responsabilite si ce message a ete >altere, deforme ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; they should not be distributed, >used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > >_______________________________________________ >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 nobody Fri Jun 12 07:07:45 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D981AC42B for ; Fri, 12 Jun 2015 07:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwImSJBguKGT for ; Fri, 12 Jun 2015 07:07: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 256531AC423 for ; Fri, 12 Jun 2015 07:07:41 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , "philippe.fouquart@orange.com" , "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEA///tFM2AAEwjgP//wzVI Date: Fri, 12 Jun 2015 14:07:19 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> , In-Reply-To: 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 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 14:07:44 -0000 There seem to be three levels:=0A= =0A= (1) Make existing SIP display name information survive NNI and VoIP-to-TDM = translation. The ATIS-SIPForum effort seems to be an appropriate venue for = that as it involves no new SIP headers or SIP behavior.=0A= =0A= (2) Allow for (but not mandate) signing the display name. We need to determ= ine whether this is just another STIR special case or not. This applies to = the (common) case where the signer of the SIP request is also in a position= to validate the caller name, using whatever internal policies they may hav= e. (In some cases, this is simply whatever the subscriber typed into a web = form, so this isn't perfect, but since the number signing will provide trac= eability, the FBI and IRS along with HSBC and Microsoft know whom to talk t= o if a customer of Joe's VoIP Service & Salvage asserts those identities. T= rademark law and civil fraud statutes seem to cover that case; the main pra= ctical difficulty today is that finding the source of the information is im= possible.)=0A= =0A= (3) Better caller name information that allows parties other than the carri= er to assert additional information.=0A= =0A= Does that cover the options?=0A= =0A= Henning=0A= =0A= =0A= ________________________________________=0A= From: Richard Shockey [richard@shockey.us]=0A= Sent: Friday, June 12, 2015 9:36 AM=0A= To: Henning Schulzrinne; philippe.fouquart@orange.com; cnit@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= =0A= =0A= RS> Well intra enterprise certainly. There it tends to get pulled from=0A= Active Directory but until we can get the NNI interface deployed its not=0A= working at all for inter enterprise. We are certainly looking at that for= =0A= Phase 2 of the NNI TF.=0A= =0A= My goal is some what more modest for a first phase. Certainly you want=0A= signed extended versions of the display name but one should not create=0A= artificial barriers to non signed data exchanges between service providers= =0A= where the security comes from the big yellow wire at Layer 1. Plus I=0A= still want a straight answer if this proposal is going to have a=0A= requirement for a new SIP header and all the IETF ART pain and suffering=0A= that goes with that. I want the AD=B9s to make that demand ( if it is to be= =0A= imposed) explicit now.=0A= From nobody Fri Jun 12 07:11:03 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94CB1AC430 for ; Fri, 12 Jun 2015 07:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJsyoik6TaYP for ; Fri, 12 Jun 2015 07:10:58 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 95F721A9234 for ; Fri, 12 Jun 2015 07:10:58 -0700 (PDT) Received: (qmail 23335 invoked by uid 0); 12 Jun 2015 14:10:58 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy4.mail.unifiedlayer.com with SMTP; 12 Jun 2015 14:10:58 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id fXk31q0141MNPNq01Xk6uk; Fri, 12 Jun 2015 13:44:06 -0600 X-Authority-Analysis: v=2.1 cv=K/SxQUmI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=jKZ029TlAAAA:8 a=OTLVf7z5AAAA:8 a=HLLxP2VMAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=bfLuiRfvAAAA:8 a=pGLkceISAAAA:8 a=a0COp8Z29grVZYDXs74A:9 a=v0bvWZ51PpDMtAHf:21 a=FwauHQ5zF4IyAzv3:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=CCjTFWRrU7+lEBncqkHUWEDuBSEjN3lzbwkQUYaI2kI=; b=b7ppr5+LrVYfOhVmhggqVFBA7e36BRNB8y3OoElYHAWT6tma9duTtduWJ3e3Mz9oVdLsiJvF6HkrIZ2kxbPuBFS4EXTn8Sr5c1CeiNGni8vTea8ZxztinXwkLbhVKpa9; Received: from [108.56.131.149] (port=49621 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z3PMF-0005R6-Hf; Fri, 12 Jun 2015 07:50:56 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Fri, 12 Jun 2015 09:50:50 -0400 From: Richard Shockey To: , "cnit@ietf.org" Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> In-Reply-To: <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 14:11:02 -0000 In North America it has been wildly popular and indeed considered essential offering for the competitive voice providers aka cable. Its a good business. There is actually consensus in the NA industry if you want interconnected point to point video to deploy some enhancement to the service is essential. The contact in the phone book is not enough. Ok sure for the 65% of calls that are part of the 20-40 numbers in your dialer but there are other applications here such as public safety where authenticated identity of the calling party may have significant benefits. It it my understanding that there are valid concerns about the Privacy/Information issues etc but really who=B9s privacy are you protecting? The calling party or the called party. I=B9ve heard the arguments. Its actually a very very interesting debate. On 6/12/15, 6:11 AM, "philippe.fouquart@orange.com" wrote: >As far as what the feature does, I think you are right. And after all, >displaying a name is..., well just that really, displaying a name and the >variations are mostly around whether the source is authoritative or to >what extent. =20 > >As to the misunderstanding relative to whether this is or isn't >implemented, I know that this hasn't been massively successful as a >feature and the need to replicate that beyond TDM isn't clear. It would >seem that most people would consider at this stage that >"matching-CLI-with-names-in-Contacts-and-displaying-the-CLI-or-anonymous-w >hen-not-present" is just good enough. Displaying names was a challenge in >environments and days when contact books weren't available and although >from an engineering perspective, not having a single format to display >may not be satisfactory or ideal for both CgP and CdP, it may actually be >a de facto happy medium for their conflicting needs for >privacy/information respectively. Probably slightly off topic for this >list. =20 > >Philippe Fouquart >Orange Labs Networks >+33 (0) 1 45 29 58 13 > >-----Message d'origine----- >De : Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >Envoy=E9 : jeudi 11 juin 2015 20:05 >=C0 : FOUQUART Philippe IMT/OLN; cnit@ietf.org >Objet : RE: [cnit] CNIT Charter bashing.. > >>From my reading, the function seems similar to caller name delivery, >>even if the mechanism is not a CNAM database. > >According to Google Translate: > >Presented coordinates are those listed in the directories. These are >necessarily the coordinates of the line holder that are displayed. The >name of the calling line holder is displayed only if the call is >presented on a compatible device. > >________________________________ >From: cnit [cnit-bounces@ietf.org] on behalf of >philippe.fouquart@orange.com [philippe.fouquart@orange.com] >Sent: Thursday, June 11, 2015 2:00 PM >To: DOLLY, MARTIN C; Richard Shockey; cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > >The feature I was referring to >http://assistance.orange.fr/presentation-du-nom-de-la-ligne-fixe-utilisati >on-4010.php >(In French, with my apologies) >As I said, it isn't a CNAM service. > >Regards, > >Philippe Fouquart >Orange Labs Networks >+33 (0) 1 45 29 58 13 > > >-------- Message d'origine -------- >De : "DOLLY, MARTIN C" >Date :11/06/2015 18:18 (GMT+01:00) >=C0 : Richard Shockey , FOUQUART Philippe IMT/OLN , cnit@ietf.org Objet : >RE: [cnit] CNIT Charter bashing.. > >I got a different answer from the Orange/FT folks at the CT WG >meetings...so please check and clarify.. > >From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey >Sent: Thursday, June 11, 2015 11:46 AM >To: philippe.fouquart@orange.com; cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > > >Thank you that is very helpful. I'm assuming its network delivered based >on information derived from the calling party billing data. > >My other running assumption has been that some form Advanced Calling Name >Delivery is a precondition for advanced realtime communications service >delivery.. Aka ubiquitous video calling. Would that be a reasonable >presumption? > >From: > >Date: Thursday, June 11, 2015 at 9:02 AM >To: "cnit@ietf.org" >> >Subject: Re: [cnit] CNIT Charter bashing.. > >Richard, > >For a number of years, there has been an optional caller name dispay >feature attached to some of the telephone services in France, but indeed >nothing like the standalone CNAM service concept that underpins the >discussions on this list. > >Regards, > >Philippe Fouquart >Orange Labs Networks >+33 (0) 1 45 29 58 13 > >-------- Message d'origine -------- >De : Richard Shockey >Date :11/06/2015 05:21 (GMT+01:00) >=C0 : Brian Rosen , Henning Schulzrinne >Cc : cnit@ietf.org >Objet : Re: [cnit] CNIT Charter bashing.. > > > >Here is what I want to know now. > >Before we start to process this concept I want to know how relevant the >existing CNAM service is deployed outside North America. > >I'm told by reliable sources that the CNAM service is not deployed >anywhere among the major telecom markets in Europe or Asia. Not Japan >China or South Korea UK Italy France and in fact it might actually be >illegal under the strict privacy regulations in Germany. > >I don't know. > >That said our friends at Apple seem to understand there is a problem >here. I have tried to engage the most senior management at Google about >who would be responsible for defining how the VoLTE CUA could actually >display an advanced call display data and frankly no one knows. > >http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-201 >5-6 > >There is a realistic question if this is simply a North American specific >problem why is this a IETF issue. You might ask the same question of >MODERN but I frankly don't want to go there. > > > > >From: Richard Shockey > >Date: Tuesday, June 2, 2015 at 12:35 PM >To: Brian Rosen > >Cc: > >Subject: Re: [cnit] CNIT Charter bashing.. > > >Hopefully but I still haven't seen any response to my concern about >normative dependencies on STIR. > >If we can define the object/headers first then I don't have a issue. > >- >Richard Shockey >Shockey Consulting LLC >Chairman of the Board SIP Forum >www.shockey.us >www.sipforum.org >richardshockey.us >Skype-Linkedin-Facebook rshockey101 >PSTN +1 703-593-2683 > > >From: Brian Rosen > >Date: Tuesday, June 2, 2015 at 12:26 PM >To: Richard Shockey > >Cc: Eric Burger=20 >>, >> >Subject: Re: [cnit] CNIT Charter bashing.. > >Are we planning to submit a charter in the next couple of days, and then >see if we can get a slot at the next IETF? > >Brian >On May 28, 2015, at 1:55 PM, Richard Shockey >> wrote: > > >A fair argument but I don't want to spend 5 years waiting for a series of >normative dependencies on the trust model before actually understanding >what headers can/should be used here. > > >Its much too difficult to get things done in the IETF as it is. I'd >much prefer building from success starting with the definition of the >data object then ..then folding that into a trust model and frankly given >what we have seen in STIR I'm not sure your argument holds up. Again the >MARTINI model. > >Didn't you recently say something about "perfection is the enemy of the >good" :-) > > > >From: Eric Burger=20 >> >Date: Wednesday, May 27, 2015 at 10:11 PM >To: > >Subject: Re: [cnit] CNIT Charter bashing.. > >On May 25, 2015, at 5:31 PM, Richard Shockey >> wrote: > >From: Mary Barnes=20 >> >Date: Friday, May 22, 2015 at 12:58 PM >Attached is what I have at this point. Really, the only thing I'm >struggling with is the milestones as I don't think we can request >publication of the data object and headers without having defined the >trust model. > > >RS> Mary I'm not sure about that statement. I can certainly anticipate >several deployment models where the trust mechanism (aka signing) does >not need to be formally integrated in the solution especially those where >the exchange of data is more bi-lateral and the trust mechanism is at >lower layers of the stack than the signaling. My initial concern is what >is the header and what is the data object(s) carried in the header. How >the CNIT data is created should not be our concern. > >I do not buy it. If there are private agreements between service >providers, they have private agreements. They can do whatever they want. > >Last I looked, this is the Internet Engineering Task Force. Assume >untrusted transport across the wide open Internet, and trust no endpoint >that cannot cryptographically prove who they are. If it happens two >service providers exchange CNIT data over a single, yellow cable, then it >is a benefit that no state-sponsored security service can listen in on >the cable. > >I do not want to take three years to build a protocol and two more years >after that for products to be available just to have a system that only >works in walled gardens. I do not want to be the person that has to >explain to the media why Calling Name Delivery is just as broken as it >always was and it will be another five years before the world sees a real >solution. > >Let us get this right the first time. >[snip] >_______________________________________________ cnit mailing list >cnit@ietf.orghttps://www.ietf.org/mailman/listinfo/c >nit >_______________________________________________ >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 > >__________________________________________________________________________ >_______________________________________________ > > > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc > >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler > >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, > >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > > > >This message and its attachments may contain confidential or privileged >information that may be protected by law; > >they should not be distributed, used or copied without authorisation. > >If you have received this email in error, please notify the sender and >delete this message and its attachments. > >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. > >Thank you. >_______________________________________________ cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >exploites ou copies sans autorisation. Si vous avez recu ce message par >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les >pieces jointes. Les messages electroniques etant susceptibles >d'alteration, Orange decline toute responsabilite si ce message a ete >altere, deforme ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; they should not be distributed, >used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit From nobody Fri Jun 12 07:13:44 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27981AC417 for ; Fri, 12 Jun 2015 07:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgauchFaJW04 for ; Fri, 12 Jun 2015 07:13:41 -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 600901A0AF1 for ; Fri, 12 Jun 2015 07:13:41 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , "philippe.fouquart@orange.com" , "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlUw== Date: Fri, 12 Jun 2015 14:13:19 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup>, In-Reply-To: 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 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 14:13:42 -0000 In almost all cases of interest, the calling party *wants* to disclose accu= rate information to the called party, so the privacy issues don't seem to a= rise. They would only arise if there was forced disclosure; I don't think a= nybody is proposing that.=0A= =0A= ________________________________________=0A= From: cnit [cnit-bounces@ietf.org] on behalf of Richard Shockey [richard@sh= ockey.us]=0A= Sent: Friday, June 12, 2015 9:50 AM=0A= To: philippe.fouquart@orange.com; cnit@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= In North America it has been wildly popular and indeed considered=0A= essential offering for the competitive voice providers aka cable. Its a=0A= good business. There is actually consensus in the NA industry if you want= =0A= interconnected point to point video to deploy some enhancement to the=0A= service is essential. The contact in the phone book is not enough. Ok sure= =0A= for the 65% of calls that are part of the 20-40 numbers in your dialer but= =0A= there are other applications here such as public safety where=0A= authenticated identity of the calling party may have significant benefits.= =0A= =0A= It it my understanding that there are valid concerns about the=0A= Privacy/Information issues etc but really who=B9s privacy are you=0A= protecting? The calling party or the called party. I=B9ve heard the=0A= arguments. Its actually a very very interesting debate.=0A= From nobody Fri Jun 12 07:17:22 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88771AC43B for ; Fri, 12 Jun 2015 07:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrfeuSvU0skQ for ; Fri, 12 Jun 2015 07:17:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348061AC437 for ; Fri, 12 Jun 2015 07:17:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 655AABE64; Fri, 12 Jun 2015 15:17:17 +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 t9SN_uFYSFRo; Fri, 12 Jun 2015 15:17:12 +0100 (IST) Received: from [129.6.253.25] (unknown [129.6.253.25]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2EB07BE54; Fri, 12 Jun 2015 15:17:10 +0100 (IST) Message-ID: <557AE9E4.5030205@cs.tcd.ie> Date: Fri, 12 Jun 2015 15:17:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Henning Schulzrinne , Richard Shockey , "philippe.fouquart@orange.com" , "cnit@ietf.org" References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup>, In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 14:17:21 -0000 On 12/06/15 15:13, Henning Schulzrinne wrote: > In almost all cases of interest, the calling party *wants* to > disclose accurate information to the called party, so the privacy > issues don't seem to arise. They would only arise if there was forced > disclosure; I don't think anybody is proposing that. Privacy issues could also arise if a middlebox could now see sensitive information that it previously could not see. I think that is independent of whether disclosure is desired by either of the endpoints. S. From nobody Fri Jun 12 08:47:20 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3261A1A32 for ; Fri, 12 Jun 2015 08:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvhCS-iltc-t for ; Fri, 12 Jun 2015 08:47:17 -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 80BB61A0338 for ; Fri, 12 Jun 2015 08:47:16 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Stephen Farrell , Richard Shockey , "philippe.fouquart@orange.com" , "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQA///U8M4= Date: Fri, 12 Jun 2015 15:47:15 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup>, , <557AE9E4.5030205@cs.tcd.ie> In-Reply-To: <557AE9E4.5030205@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 15:47:20 -0000 Good point, although I suspect that a business or individual that wants to = disclose its name to the recipient and obviously already discloses its numb= er to all carriers along the way seems unlikely to care that the carrier ca= n also see its name. After all, today, all such carriers have access to CNA= M information (along with others). At least in the US, the carriers are lar= gely bound by strict privacy rules ("customer proprietary network informati= on") that carriers tend to take very seriously. (I say "largely", because t= here may be entities such as CNAM providers and VoIP providers that are con= sidering themselves not to be interconnected that are in the not-quite-carr= ier area.)=0A= =0A= ________________________________________=0A= From: Stephen Farrell [stephen.farrell@cs.tcd.ie]=0A= Sent: Friday, June 12, 2015 10:17 AM=0A= To: Henning Schulzrinne; Richard Shockey; philippe.fouquart@orange.com; cni= t@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= On 12/06/15 15:13, Henning Schulzrinne wrote:=0A= > In almost all cases of interest, the calling party *wants* to=0A= > disclose accurate information to the called party, so the privacy=0A= > issues don't seem to arise. They would only arise if there was forced=0A= > disclosure; I don't think anybody is proposing that.=0A= =0A= Privacy issues could also arise if a middlebox could now see=0A= sensitive information that it previously could not see. I think=0A= that is independent of whether disclosure is desired by either=0A= of the endpoints.=0A= =0A= S.=0A= =0A= From nobody Fri Jun 12 09:02:15 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9841A1BF8 for ; Fri, 12 Jun 2015 09:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LivPXBks7nJy for ; Fri, 12 Jun 2015 09:02:12 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 41FB81A1BFF for ; Fri, 12 Jun 2015 09:01:55 -0700 (PDT) Received: (qmail 21102 invoked by uid 0); 12 Jun 2015 16:01:54 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy1.mail.unifiedlayer.com with SMTP; 12 Jun 2015 16:01:54 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id fZaf1q0141MNPNq01ZaikP; Fri, 12 Jun 2015 15:34:43 -0600 X-Authority-Analysis: v=2.1 cv=VOtOwb/X c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=XW0vzNQbW2AA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=x2SC4MuZadmF-8auNKEA:9 a=_RucbEbWqVscLUrN:21 a=CXoYhGVU1djeu7_x:21 a=Spabb166XhwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=5K+psb+77lGHgGPQkcJIYi8wYLWC6bIvb3sM/dVjt8Y=; b=HoiBUaXDJIBzpQTgc+wFASlRB7m69/1K5MD4WCyGK5JLfjBcVqasJFha/Lf5wYpuZmFe/QjFLptlaQkZz/q7X9+WyhojQ5A5CfkARrgIGx2BuA9xpKm0CBk1JAzJFijz; Received: from [108.56.131.149] (port=50617 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z3R5a-0001ek-MC; Fri, 12 Jun 2015 09:41:50 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Fri, 12 Jun 2015 11:41:45 -0400 From: Richard Shockey To: Henning Schulzrinne , "philippe.fouquart@orange.com" , "cnit@ietf.org" Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:02:14 -0000 On 6/12/15, 10:07 AM, "Henning Schulzrinne" wrote: >There seem to be three levels: > >(1) Make existing SIP display name information survive NNI and >VoIP-to-TDM translation. The ATIS-SIPForum effort seems to be an >appropriate venue for that as it involves no new SIP headers or SIP >behavior. RS> Correct. That is definitely on the agenda for Phase 2 of the NNI. > >(2) Allow for (but not mandate) signing the display name. We need to >determine whether this is just another STIR special case or not. This >applies to the (common) case where the signer of the SIP request is also >in a position to validate the caller name, using whatever internal >policies they may have. (In some cases, this is simply whatever the >subscriber typed into a web form, so this isn't perfect, but since the >number signing will provide traceability, the FBI and IRS along with HSBC >and Microsoft know whom to talk to if a customer of Joe's VoIP Service & >Salvage asserts those identities. Trademark law and civil fraud statutes >seem to cover that case; the main practical difficulty today is that >finding the source of the information is impossible.) RS> Correct. My initial use case is a relatively simple voluntary extension of the existing SP to SP system where additional information is passed in the signaling. The issue is where does that information sit in the headers (existing or new ) and how does the CUA display it. Beyond that it becomes more complicated and I think that given the general public policy concerns, developing incremental solutions can work within existing framework and after all right now the vast majority of existing SIP interconnection for voice in NA is directly interconnected and may not use BGP routing at all. Mandated solutions for data validation and signing are needed but given the complexity of the infrastructure necessary to deploy such solutions mandating signing in the CNIT charter would unacceptably delay progress. > >(3) Better caller name information that allows parties other than the >carrier to assert additional information. RS> Yes. But ptionally. But right now the originating carrier has the principal business relationship with the calling party that can be leveraged. There are several ideas being kicked around for that including RFC 7095. > >Does that cover the options? > >Henning > > >________________________________________ >From: Richard Shockey [richard@shockey.us] >Sent: Friday, June 12, 2015 9:36 AM >To: Henning Schulzrinne; philippe.fouquart@orange.com; cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > > > >RS> Well intra enterprise certainly. There it tends to get pulled from >Active Directory but until we can get the NNI interface deployed its not >working at all for inter enterprise. We are certainly looking at that for >Phase 2 of the NNI TF. > >My goal is some what more modest for a first phase. Certainly you want >signed extended versions of the display name but one should not create >artificial barriers to non signed data exchanges between service providers >where the security comes from the big yellow wire at Layer 1. Plus I >still want a straight answer if this proposal is going to have a >requirement for a new SIP header and all the IETF ART pain and suffering >that goes with that. I want the AD=A9=F6s to make that demand ( if it is to be >imposed) explicit now. From nobody Fri Jun 12 09:10:12 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9BF1A1B48 for ; Fri, 12 Jun 2015 09:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgP1FB_RoISw for ; Fri, 12 Jun 2015 09:10:09 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id E8D7C1A1B34 for ; Fri, 12 Jun 2015 09:10:08 -0700 (PDT) Received: (qmail 32644 invoked by uid 0); 12 Jun 2015 16:10:08 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 12 Jun 2015 16:10:08 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id fTiN1q0071MNPNq01TiR0V; Fri, 12 Jun 2015 09:42:33 -0600 X-Authority-Analysis: v=2.1 cv=cooIzTIi c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=kj9zAlcOel0A:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=5ghfHOtlzQCDLEinPWYA:9 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=aBJhJKbZqrzA8EJEMUKXoRyfIv7x+POxI0jCqQJ6G+Q=; b=Ul36EwG38aOz8Hgp01He4jH0EyZL6WPNvCFrVuzinHReBFC/A7vrVZsG1TA+phBKJ0uRVk8cd/9xT/WIVZ9ceoCsWbP9qg9uwQRSSmhgy/3Ue3GwApoD5c2/4ElWdEAA; Received: from [108.56.131.149] (port=50625 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z3RDR-0007ZD-Ey; Fri, 12 Jun 2015 09:49:57 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Fri, 12 Jun 2015 11:49:52 -0400 From: Richard Shockey To: Stephen Farrell , Henning Schulzrinne , "philippe.fouquart@orange.com" , "cnit@ietf.org" Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> In-Reply-To: <557AE9E4.5030205@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:10:11 -0000 Henning is right. No one is forcing anything. Existing anonymous calling protections still apply. Again my point is that is a great many cases Interconnected SIP between NA carriers are covered by other security mechanisms. Right now your Facetime session is totally in the clear. My concern is we end up going down the rat hole of trying to create perfect end to end security nothing will get done. On 6/12/15, 10:17 AM, "Stephen Farrell" wrote: > > >On 12/06/15 15:13, Henning Schulzrinne wrote: >> In almost all cases of interest, the calling party *wants* to >> disclose accurate information to the called party, so the privacy >> issues don't seem to arise. They would only arise if there was forced >> disclosure; I don't think anybody is proposing that. > >Privacy issues could also arise if a middlebox could now see >sensitive information that it previously could not see. I think >that is independent of whether disclosure is desired by either >of the endpoints. > >S. > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit From nobody Fri Jun 12 09:28:31 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332B51A8755 for ; Fri, 12 Jun 2015 09:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9-ChaS-FWpa for ; Fri, 12 Jun 2015 09:28:27 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205A41A9085 for ; Fri, 12 Jun 2015 09:28:27 -0700 (PDT) Received: by qcjq9 with SMTP id q9so7166186qcj.2 for ; Fri, 12 Jun 2015 09:28:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=T4B/e2w2qzQbXyFracGbj54ewCj5QyjwjlqdJkR4yRk=; b=edVaPIiOW58Ai6oSW+FmAAHnPwCdm4WM+R3lDCB+twhJPBmF056aWUrt308PmkwGY/ ZESmFJWuD9/vddsBBNsHpNQT8QSZnXFnTJhcw1sKJQDfg7/e9UHqbeJD7aOVLedk9OXs +Z90qxiiKC60iFOr9y8vdm2Ox3//8ClUwSQFZyt1Nc3gPv1Cy/XL8wXYzY8ijvTCK09b gnDxQ3hB9mrxudhO/jhau59hG2zzs3I/esSH0oSPF1cRf8rrbEkrvi96gA1IJojejbIQ HJbF5sFoVGf67aGfq/hkWsx8I19H5yGKCpSdZTRMIzR0PVMgxSG9+Nv9I9zgtKOpL+cT vP/A== X-Gm-Message-State: ALoCoQl9KXGT2BdmTueW61KPp1NuED00hSC9c35MVU2Qbr0UKK7hpgK4dQnam10QM5694iemGOGl X-Received: by 10.140.97.136 with SMTP id m8mr19461193qge.32.1434126506398; Fri, 12 Jun 2015 09:28:26 -0700 (PDT) Received: from [10.33.128.56] ([156.154.61.4]) by mx.google.com with ESMTPSA id l81sm1856391qhl.24.2015.06.12.09.28.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 09:28:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Brian Rosen In-Reply-To: Date: Fri, 12 Jun 2015 09:28:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> To: Richard Shockey X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "philippe.fouquart@orange.com" , Henning Schulzrinne , "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:28:29 -0000 One possible extra bit is that we need to know WHO signed. That could = be easy (identity in a cert for the signature), but it=E2=80=99s a = requirement. I still want an optional confidence value, because the source is often = not authoritative. If we=E2=80=99re thinking we=E2=80=99re using the existing display name, = and coming up with a way to sign it, then, like stir, the termination = side can decide what it wants to do if it gets a display name but no = signature. The sender has the option to provide the name or not, and = provide the signature or not. We COULD consider a new header that would contain the name encrypted for = a destination TN (To:). That would afford privacy to the name to middle = boxes that we would not have today with display name. I would not be = opposed to that. This would work like the offline stir proposal, where = the sender obtains the public key of the recipient and encrypts the name = for the recipient. Brian > On Jun 12, 2015, at 8:49 AM, Richard Shockey = wrote: >=20 >=20 > Henning is right. No one is forcing anything. Existing anonymous = calling > protections still apply. >=20 >=20 > Again my point is that is a great many cases Interconnected SIP = between NA > carriers are covered by other security mechanisms. >=20 > Right now your Facetime session is totally in the clear. My concern is = we > end up going down the rat hole of trying to create perfect end to end > security nothing will get done. >=20 >=20 >=20 > On 6/12/15, 10:17 AM, "Stephen Farrell" = wrote: >=20 >>=20 >>=20 >> On 12/06/15 15:13, Henning Schulzrinne wrote: >>> In almost all cases of interest, the calling party *wants* to >>> disclose accurate information to the called party, so the privacy >>> issues don't seem to arise. They would only arise if there was = forced >>> disclosure; I don't think anybody is proposing that. >>=20 >> Privacy issues could also arise if a middlebox could now see >> sensitive information that it previously could not see. I think >> that is independent of whether disclosure is desired by either >> of the endpoints. >>=20 >> S. >>=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 nobody Fri Jun 12 09:48:36 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314381A87ED for ; Fri, 12 Jun 2015 09:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z78BlG_v5pq for ; Fri, 12 Jun 2015 09:48:33 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8081A87CC for ; Fri, 12 Jun 2015 09:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434127714; x=1465663714; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=i/SnMa79OvG9++SGwW41pAsTmz6nSjEbArvEa4us7Jw=; b=W857YY9Bafawm4KJdcZv1NHX4c848T/P7N7f3D0EJ1yXUsFXXxHjUvFM Yih8edn+eA+xKu9qyZ88LktNunrJ2A04qVFMhltt3m6wEbiTmo+g/gHAZ tvLc4O23DyHAtmv4005c4Z69ruKum6kbKCrERVCQvm+P+2FxxY9UIWVwl k=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 12 Jun 2015 16:48:33 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.13,602,1427760000"; d="scan'208";a="28216440" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 12 Jun 2015 16:48:31 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Fri, 12 Jun 2015 12:47:57 -0400 To: Richard Shockey , Stephen Farrell , Henning Schulzrinne , "philippe.fouquart@orange.com" , "cnit@ietf.org" Date: Fri, 12 Jun 2015 12:47:56 -0400 Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AdClKkUdIXswVnj6RCiRWdrHP1en3AAA+r1Q Message-ID: <2B0F677F0B95454297753F58D4A07FA30279326B59@FHDP1LUMXC7V31.us.one.verizon.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> In-Reply-To: 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 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:48:35 -0000 Rich, I'm probably not following this right, so bear with me. In the current par= adigm the calling party's name isn't sent in the call request message, righ= t? But you're proposing that it should be (or optionally could be, whateve= r). Doesn't that open up the possibility Mr. Farrell suggested, that some = entity that's in the path of the call request message can "see" something h= e previously could not? Note that "existing anonymous calling protections" apply to the presentatio= n of information to the user, not necessarily to carriage of information ac= ross the network. The FROM header may be anonymized when the calling user = requests privacy, for example, but the P-Asserted-Identity header will not.= So if we were to use the display name in the P-A-ID to carry the calling = party name asserted by the originating network, that name would (unless we = encrypt it) be "visible" to any network element on the path of the INVITE. = =20 tim -----Original Message----- From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Friday, June 12, 2015 10:50 AM To: Stephen Farrell; Henning Schulzrinne; philippe.fouquart@orange.com; cni= t@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. Henning is right. No one is forcing anything. Existing anonymous calling pr= otections still apply. Again my point is that is a great many cases Interconnected SIP between NA = carriers are covered by other security mechanisms. Right now your Facetime session is totally in the clear. My concern is we e= nd up going down the rat hole of trying to create perfect end to end securi= ty nothing will get done. On 6/12/15, 10:17 AM, "Stephen Farrell" wrote: > > >On 12/06/15 15:13, Henning Schulzrinne wrote: >> In almost all cases of interest, the calling party *wants* to=20 >> disclose accurate information to the called party, so the privacy=20 >> issues don't seem to arise. They would only arise if there was forced=20 >> disclosure; I don't think anybody is proposing that. > >Privacy issues could also arise if a middlebox could now see sensitive=20 >information that it previously could not see. I think that is=20 >independent of whether disclosure is desired by either of the=20 >endpoints. > >S. > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From nobody Fri Jun 12 09:56:52 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EE01AC44B for ; Fri, 12 Jun 2015 09:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6-2DKHzRBHl for ; Fri, 12 Jun 2015 09:56:49 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34A31AC3FD for ; Fri, 12 Jun 2015 09:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434128198; x=1465664198; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=V0p7g7YX6QyqtZ1CFX+kGCXwqT2YL0iGn0GfQRLWF5o=; b=nwxUZd8H08YglNUCmq4gYq9bCqrgokxXELFsKbXM8eJD+MPHLHXgKccx 8Ma4xMWhHGNNX3SsiURZJCZ9xZO0o+nrlqZOUEOrhb+1m3OnFZvsG0Bri DVDSDT+LsIZWnV/UU/s/s/l3HXU03HZYLmI3ZYHTZAUo9G+Rvd+zahb3D 4=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 12 Jun 2015 16:56:28 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.13,602,1427760000"; d="scan'208";a="28219071" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 12 Jun 2015 16:56:27 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Fri, 12 Jun 2015 12:56:27 -0400 To: Brian Rosen , Richard Shockey Date: Fri, 12 Jun 2015 12:56:26 -0400 Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AdClLNMjfPR59z0iT464Q0dnic1lgwAAuJdw Message-ID: <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> In-Reply-To: <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "philippe.fouquart@orange.com" , "cnit@ietf.org" , Stephen Farrell , Henning Schulzrinne Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:56:51 -0000 V2hvIHdvdWxkIGFzc2lnbiB0aGUgY29uZmlkZW5jZSB2YWx1ZT8gIElmIGl0J3MgYXNzaWduZWQg YnkgdGhlIGVudGl0eSB0aGF0IG9wZXJhdGVzIHRoZSBjYWxsaW5nIG5hbWUgZGF0YWJhc2UsIHdo eSB3b3VsZCBpdCBldmVyIGJlIGxlc3MgdGhhbiB0aGUgaGlnaGVzdCBwb3NzaWJsZSB2YWx1ZT8g IElmIGl0J3Mgc2V0IGJ5IHNvbWUgb3RoZXIgZW50aXR5LCBvbiB3aGF0IGJhc2lzIGRvIHRoZXkg ZGV0ZXJtaW5lIHRoZSB2YWx1ZSB0aGV5IGFzc2lnbj8gIEl0IHNlZW1zIGxpa2Ugd2UncmUgZ29p bmcgdG8gc3R1bWJsZSBvdmVyIGJ1c2luZXNzIGlzc3Vlcy4NCg0KVGltDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNuaXQgW21haWx0bzpjbml0LWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbg0KU2VudDogRnJpZGF5LCBKdW5lIDEyLCAyMDE1 IDExOjI4IEFNDQpUbzogUmljaGFyZCBTaG9ja2V5DQpDYzogcGhpbGlwcGUuZm91cXVhcnRAb3Jh bmdlLmNvbTsgSGVubmluZyBTY2h1bHpyaW5uZTsgY25pdEBpZXRmLm9yZzsgU3RlcGhlbiBGYXJy ZWxsDQpTdWJqZWN0OiBSZTogW2NuaXRdIENOSVQgQ2hhcnRlciBiYXNoaW5nLi4NCg0KT25lIHBv c3NpYmxlIGV4dHJhIGJpdCBpcyB0aGF0IHdlIG5lZWQgdG8ga25vdyBXSE8gc2lnbmVkLiAgVGhh dCBjb3VsZCBiZSBlYXN5IChpZGVudGl0eSBpbiBhIGNlcnQgZm9yIHRoZSBzaWduYXR1cmUpLCBi dXQgaXTigJlzIGEgcmVxdWlyZW1lbnQuDQoNCkkgc3RpbGwgd2FudCBhbiBvcHRpb25hbCBjb25m aWRlbmNlIHZhbHVlLCBiZWNhdXNlIHRoZSBzb3VyY2UgaXMgb2Z0ZW4gbm90IGF1dGhvcml0YXRp dmUuDQoNCklmIHdl4oCZcmUgdGhpbmtpbmcgd2XigJlyZSB1c2luZyB0aGUgZXhpc3RpbmcgZGlz cGxheSBuYW1lLCBhbmQgY29taW5nIHVwIHdpdGggYSB3YXkgdG8gc2lnbiBpdCwgdGhlbiwgbGlr ZSBzdGlyLCB0aGUgdGVybWluYXRpb24gc2lkZSBjYW4gZGVjaWRlIHdoYXQgaXQgd2FudHMgdG8g ZG8gaWYgaXQgZ2V0cyBhIGRpc3BsYXkgbmFtZSBidXQgbm8gc2lnbmF0dXJlLiAgVGhlIHNlbmRl ciBoYXMgdGhlIG9wdGlvbiB0byBwcm92aWRlIHRoZSBuYW1lIG9yIG5vdCwgYW5kIHByb3ZpZGUg dGhlIHNpZ25hdHVyZSBvciBub3QuDQoNCldlIENPVUxEIGNvbnNpZGVyIGEgbmV3IGhlYWRlciB0 aGF0IHdvdWxkIGNvbnRhaW4gdGhlIG5hbWUgZW5jcnlwdGVkIGZvciBhIGRlc3RpbmF0aW9uIFRO IChUbzopLiAgVGhhdCB3b3VsZCBhZmZvcmQgcHJpdmFjeSB0byB0aGUgbmFtZSB0byBtaWRkbGUg Ym94ZXMgdGhhdCB3ZSB3b3VsZCBub3QgaGF2ZSB0b2RheSB3aXRoIGRpc3BsYXkgbmFtZS4gIEkg d291bGQgbm90IGJlIG9wcG9zZWQgdG8gdGhhdC4gIFRoaXMgd291bGQgd29yayBsaWtlIHRoZSBv ZmZsaW5lIHN0aXIgcHJvcG9zYWwsIHdoZXJlIHRoZSBzZW5kZXIgb2J0YWlucyB0aGUgcHVibGlj IGtleSBvZiB0aGUgcmVjaXBpZW50IGFuZCBlbmNyeXB0cyB0aGUgbmFtZSBmb3IgdGhlIHJlY2lw aWVudC4NCg0KQnJpYW4NCg0KPiBPbiBKdW4gMTIsIDIwMTUsIGF0IDg6NDkgQU0sIFJpY2hhcmQg U2hvY2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPiB3cm90ZToNCj4gDQo+IA0KPiBIZW5uaW5nIGlz IHJpZ2h0LiBObyBvbmUgaXMgZm9yY2luZyBhbnl0aGluZy4gRXhpc3RpbmcgYW5vbnltb3VzIA0K PiBjYWxsaW5nIHByb3RlY3Rpb25zIHN0aWxsIGFwcGx5Lg0KPiANCj4gDQo+IEFnYWluIG15IHBv aW50IGlzIHRoYXQgaXMgYSBncmVhdCBtYW55IGNhc2VzIEludGVyY29ubmVjdGVkIFNJUCANCj4g YmV0d2VlbiBOQSBjYXJyaWVycyBhcmUgY292ZXJlZCBieSBvdGhlciBzZWN1cml0eSBtZWNoYW5p c21zLg0KPiANCj4gUmlnaHQgbm93IHlvdXIgRmFjZXRpbWUgc2Vzc2lvbiBpcyB0b3RhbGx5IGlu IHRoZSBjbGVhci4gTXkgY29uY2VybiBpcyANCj4gd2UgZW5kIHVwIGdvaW5nIGRvd24gdGhlIHJh dCBob2xlIG9mIHRyeWluZyB0byBjcmVhdGUgcGVyZmVjdCBlbmQgdG8gDQo+IGVuZCBzZWN1cml0 eSBub3RoaW5nIHdpbGwgZ2V0IGRvbmUuDQo+IA0KPiANCj4gDQo+IE9uIDYvMTIvMTUsIDEwOjE3 IEFNLCAiU3RlcGhlbiBGYXJyZWxsIiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6 DQo+IA0KPj4gDQo+PiANCj4+IE9uIDEyLzA2LzE1IDE1OjEzLCBIZW5uaW5nIFNjaHVsenJpbm5l IHdyb3RlOg0KPj4+IEluIGFsbW9zdCBhbGwgY2FzZXMgb2YgaW50ZXJlc3QsIHRoZSBjYWxsaW5n IHBhcnR5ICp3YW50cyogdG8gDQo+Pj4gZGlzY2xvc2UgYWNjdXJhdGUgaW5mb3JtYXRpb24gdG8g dGhlIGNhbGxlZCBwYXJ0eSwgc28gdGhlIHByaXZhY3kgDQo+Pj4gaXNzdWVzIGRvbid0IHNlZW0g dG8gYXJpc2UuIFRoZXkgd291bGQgb25seSBhcmlzZSBpZiB0aGVyZSB3YXMgDQo+Pj4gZm9yY2Vk IGRpc2Nsb3N1cmU7IEkgZG9uJ3QgdGhpbmsgYW55Ym9keSBpcyBwcm9wb3NpbmcgdGhhdC4NCj4+ IA0KPj4gUHJpdmFjeSBpc3N1ZXMgY291bGQgYWxzbyBhcmlzZSBpZiBhIG1pZGRsZWJveCBjb3Vs ZCBub3cgc2VlIA0KPj4gc2Vuc2l0aXZlIGluZm9ybWF0aW9uIHRoYXQgaXQgcHJldmlvdXNseSBj b3VsZCBub3Qgc2VlLiBJIHRoaW5rIHRoYXQgDQo+PiBpcyBpbmRlcGVuZGVudCBvZiB3aGV0aGVy IGRpc2Nsb3N1cmUgaXMgZGVzaXJlZCBieSBlaXRoZXIgb2YgdGhlIA0KPj4gZW5kcG9pbnRzLg0K Pj4gDQo+PiBTLg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gY25pdCBtYWlsaW5nIGxpc3QNCj4+IGNuaXRAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY25pdA0KPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNuaXQgbWFpbGlu ZyBsaXN0DQo+IGNuaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jbml0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpjbml0IG1haWxpbmcgbGlzdA0KY25pdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbml0DQo= From nobody Fri Jun 12 10:51:21 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2776A1ACE48 for ; Fri, 12 Jun 2015 10:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYqhxx4YUGGb for ; Fri, 12 Jun 2015 10:51:18 -0700 (PDT) Received: from mail-vn0-f47.google.com (mail-vn0-f47.google.com [209.85.216.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30F91ACE47 for ; Fri, 12 Jun 2015 10:51:17 -0700 (PDT) Received: by vnbg7 with SMTP id g7so7167827vnb.10 for ; Fri, 12 Jun 2015 10:51: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=IX6PjLFTbkBtz3h6CbHRTFWiJE2Wyn/P7SFzUeVibWc=; b=WBf8zgG3ltFln5Vfi5BOEl/b5M+Q5Ae5zbpA4bCJec4t8ay4iZeOO9mCLOuHdP+ehp UT3sr3I4Ds7RXJdY6HxwtBwDAJTE2jqB7gXDZqYgd3Adwgcp1dKN2lkLekMU/jSjP0DM JnGxwnz2rB0t7b9/06xnUvtrbjYtYC5rAbvRl0Rb6hTYV8w6A0TG26OUkYiGkC/rFekc eSLseYyZLTQYJgG4CqEXb8s1enr/07s7ZdKPWzzfScFw1qHUiDbtAqKsUCy+SgU7Q59c avm2voq0ZpLmm/u4DY3hogFt8hDkSqi0MGKLX+Zf1tcYiGnVpp3I4LQ/8CVE4s6KwAub KR5g== X-Gm-Message-State: ALoCoQmTucUdK+4t1YrxNz5fAohpN+30N7P+bL9V+gy3yy5XFl3y68Tv5O/jo4sdG2zoPEyVBjM1 X-Received: by 10.52.36.39 with SMTP id n7mr27760221vdj.19.1434131476958; Fri, 12 Jun 2015 10:51:16 -0700 (PDT) Received: from [10.33.128.56] ([156.154.61.4]) by mx.google.com with ESMTPSA id fi9sm5169174vdb.27.2015.06.12.10.51.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 10:51:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Brian Rosen In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> Date: Fri, 12 Jun 2015 10:51:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> To: "Dwight, Timothy M (Tim)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "philippe.fouquart@orange.com" , Henning Schulzrinne , "cnit@ietf.org" , Stephen Farrell , Richard Shockey Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 17:51:20 -0000 Yes, it would be assigned by the entity that signed the name. It=E2=80=99s not true that it would always be the highest possible = value. If the entity that provided it did that, the receiving entity = might not believe it, and choose to use an alternative name source (or = at least check another service to see what it thought). Modern systems = that collect names subject user data with verification sources that are = getting very accurate, but those services have scoring systems that = don=E2=80=99t result in black/white results. Older systems blithely = accept whatever the customer says, and those are not accurate. Some = services have something simpler, like the name has to match a credit = card name, but we know those are pretty spoofable these days. Real = systems use external verification services that provide scores for this = kind of thing. I=E2=80=99m simply proposing that we allow an optional confidence, in = the range of 0-100, and that it be part of the data signed by the data = provider. No one has to send it, no one has to look at it. But it = represents what is state of the art these days on asserting names and I = think it=E2=80=99s valuable. Brian > On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) = wrote: >=20 > Who would assign the confidence value? If it's assigned by the entity = that operates the calling name database, why would it ever be less than = the highest possible value? If it's set by some other entity, on what = basis do they determine the value they assign? It seems like we're = going to stumble over business issues. >=20 > Tim >=20 >=20 > -----Original Message----- > From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Friday, June 12, 2015 11:28 AM > To: Richard Shockey > Cc: philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org; = Stephen Farrell > Subject: Re: [cnit] CNIT Charter bashing.. >=20 > One possible extra bit is that we need to know WHO signed. That could = be easy (identity in a cert for the signature), but it=E2=80=99s a = requirement. >=20 > I still want an optional confidence value, because the source is often = not authoritative. >=20 > If we=E2=80=99re thinking we=E2=80=99re using the existing display = name, and coming up with a way to sign it, then, like stir, the = termination side can decide what it wants to do if it gets a display = name but no signature. The sender has the option to provide the name or = not, and provide the signature or not. >=20 > We COULD consider a new header that would contain the name encrypted = for a destination TN (To:). That would afford privacy to the name to = middle boxes that we would not have today with display name. I would = not be opposed to that. This would work like the offline stir proposal, = where the sender obtains the public key of the recipient and encrypts = the name for the recipient. >=20 > Brian >=20 >> On Jun 12, 2015, at 8:49 AM, Richard Shockey = wrote: >>=20 >>=20 >> Henning is right. No one is forcing anything. Existing anonymous=20 >> calling protections still apply. >>=20 >>=20 >> Again my point is that is a great many cases Interconnected SIP=20 >> between NA carriers are covered by other security mechanisms. >>=20 >> Right now your Facetime session is totally in the clear. My concern = is=20 >> we end up going down the rat hole of trying to create perfect end to=20= >> end security nothing will get done. >>=20 >>=20 >>=20 >> On 6/12/15, 10:17 AM, "Stephen Farrell" = wrote: >>=20 >>>=20 >>>=20 >>> On 12/06/15 15:13, Henning Schulzrinne wrote: >>>> In almost all cases of interest, the calling party *wants* to=20 >>>> disclose accurate information to the called party, so the privacy=20= >>>> issues don't seem to arise. They would only arise if there was=20 >>>> forced disclosure; I don't think anybody is proposing that. >>>=20 >>> Privacy issues could also arise if a middlebox could now see=20 >>> sensitive information that it previously could not see. I think that=20= >>> is independent of whether disclosure is desired by either of the=20 >>> endpoints. >>>=20 >>> S. >>>=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 nobody Fri Jun 12 12:21:29 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4013C1ACF1B for ; Fri, 12 Jun 2015 12:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THINMV8JPNt5 for ; Fri, 12 Jun 2015 12:21:25 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC5E1ACEFD for ; Fri, 12 Jun 2015 12:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434136884; x=1465672884; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aa/s4g5t3dWZpgmUc3cUla4h2I672NVEv/fkgWvVlro=; b=rCvlhWd651itkgf9E0k0rnAbt88cx8zWF5ZkWNLnkQvsSJrEgtqvMTpL 7SGIvSrCw7hbPZdmweArSE0ch1rSMab712S+sXxekb9EnSV6DiBDoOp1r 6s2wVd8zIdwSxBsw5NqBeB6Wg9YpweDr7ekBxRd9CLyR1scCLqVmjnUq/ w=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 12 Jun 2015 19:21:23 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.13,602,1427760000"; d="scan'208";a="28276135" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 12 Jun 2015 19:21:23 +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, 12 Jun 2015 15:21:22 -0400 To: Brian Rosen Date: Fri, 12 Jun 2015 15:21:21 -0400 Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AdClOGLvhR3gbQf2RfKzIqe3bJsTBwAC7XZA Message-ID: <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> In-Reply-To: <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "philippe.fouquart@orange.com" , Henning Schulzrinne , "cnit@ietf.org" , Stephen Farrell , Richard Shockey Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 19:21:27 -0000 SSBndWVzcyBhcyBsb25nIGFzIHRoZSBkZXJpdmF0aW9uIG9mIHRoZSBuYW1lICh3aG8gaXMgYXNz ZXJ0aW5nIGl0IHRvIGJlIGEgdmFsaWQgcmVwcmVzZW50YXRpb24gb2YgdGhlIGNhbGxlciwgYW5k IGZyb20gd2hlcmUgZGlkIHRoZXkgZ2V0IGl0KSBpcyBjbGVhciB0byB0aGUgcmVjZWl2aW5nIG5l dHdvcmssIEkgZ3Vlc3MgdGhpcyBpcyBPSy4gIEkgc3RpbGwgaGF2ZSBteSBkb3VidHMgd2hldGhl ciBzdWNoIGEgdmFsdWUgd2lsbCBwcm92ZSB1c2VmdWwsIGdpdmVuIHRoYXQgaXRzIGNvbXB1dGF0 aW9uIGlzIG5vdCBzdGFuZGFyZGl6ZWQuICBCdXQgaW4gc29tZSBjb250ZXh0cywgaXQgbWlnaHQu DQoNClRpbQ0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gUm9z ZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0gDQpTZW50OiBGcmlkYXksIEp1bmUgMTIsIDIw MTUgMTI6NTEgUE0NClRvOiBEd2lnaHQsIFRpbW90aHkgTSAoVGltKQ0KQ2M6IFJpY2hhcmQgU2hv Y2tleTsgcGhpbGlwcGUuZm91cXVhcnRAb3JhbmdlLmNvbTsgSGVubmluZyBTY2h1bHpyaW5uZTsg Y25pdEBpZXRmLm9yZzsgU3RlcGhlbiBGYXJyZWxsDQpTdWJqZWN0OiBSZTogW2NuaXRdIENOSVQg Q2hhcnRlciBiYXNoaW5nLi4NCg0KWWVzLCBpdCB3b3VsZCBiZSBhc3NpZ25lZCBieSB0aGUgZW50 aXR5IHRoYXQgc2lnbmVkIHRoZSBuYW1lLg0KDQpJdOKAmXMgbm90IHRydWUgdGhhdCBpdCB3b3Vs ZCBhbHdheXMgYmUgdGhlIGhpZ2hlc3QgcG9zc2libGUgdmFsdWUuICBJZiB0aGUgZW50aXR5IHRo YXQgcHJvdmlkZWQgaXQgZGlkIHRoYXQsIHRoZSByZWNlaXZpbmcgZW50aXR5IG1pZ2h0IG5vdCBi ZWxpZXZlIGl0LCBhbmQgY2hvb3NlIHRvIHVzZSBhbiBhbHRlcm5hdGl2ZSBuYW1lIHNvdXJjZSAo b3IgYXQgbGVhc3QgY2hlY2sgYW5vdGhlciBzZXJ2aWNlIHRvIHNlZSB3aGF0IGl0IHRob3VnaHQp LiAgTW9kZXJuIHN5c3RlbXMgdGhhdCBjb2xsZWN0IG5hbWVzIHN1YmplY3QgdXNlciBkYXRhIHdp dGggdmVyaWZpY2F0aW9uIHNvdXJjZXMgdGhhdCBhcmUgZ2V0dGluZyB2ZXJ5IGFjY3VyYXRlLCBi dXQgdGhvc2Ugc2VydmljZXMgaGF2ZSBzY29yaW5nIHN5c3RlbXMgdGhhdCBkb27igJl0IHJlc3Vs dCBpbiBibGFjay93aGl0ZSByZXN1bHRzLiAgT2xkZXIgc3lzdGVtcyBibGl0aGVseSBhY2NlcHQg d2hhdGV2ZXIgdGhlIGN1c3RvbWVyIHNheXMsIGFuZCB0aG9zZSBhcmUgbm90IGFjY3VyYXRlLiAg U29tZSBzZXJ2aWNlcyBoYXZlIHNvbWV0aGluZyBzaW1wbGVyLCBsaWtlIHRoZSBuYW1lIGhhcyB0 byBtYXRjaCBhIGNyZWRpdCBjYXJkIG5hbWUsIGJ1dCB3ZSBrbm93IHRob3NlIGFyZSBwcmV0dHkg c3Bvb2ZhYmxlIHRoZXNlIGRheXMuICBSZWFsIHN5c3RlbXMgdXNlIGV4dGVybmFsIHZlcmlmaWNh dGlvbiBzZXJ2aWNlcyB0aGF0IHByb3ZpZGUgc2NvcmVzIGZvciB0aGlzIGtpbmQgb2YgdGhpbmcu DQoNCknigJltIHNpbXBseSBwcm9wb3NpbmcgdGhhdCB3ZSBhbGxvdyBhbiBvcHRpb25hbCBjb25m aWRlbmNlLCBpbiB0aGUgcmFuZ2Ugb2YgMC0xMDAsIGFuZCB0aGF0IGl0IGJlIHBhcnQgb2YgdGhl IGRhdGEgc2lnbmVkIGJ5IHRoZSBkYXRhIHByb3ZpZGVyLiAgTm8gb25lIGhhcyB0byBzZW5kIGl0 LCBubyBvbmUgaGFzIHRvIGxvb2sgYXQgaXQuICBCdXQgaXQgcmVwcmVzZW50cyB3aGF0IGlzIHN0 YXRlIG9mIHRoZSBhcnQgdGhlc2UgZGF5cyBvbiBhc3NlcnRpbmcgbmFtZXMgYW5kIEkgdGhpbmsg aXTigJlzIHZhbHVhYmxlLg0KDQpCcmlhbg0KPiBPbiBKdW4gMTIsIDIwMTUsIGF0IDk6NTYgQU0s IER3aWdodCwgVGltb3RoeSBNIChUaW0pIDx0aW1vdGh5LmR3aWdodEB2ZXJpem9uLmNvbT4gd3Jv dGU6DQo+IA0KPiBXaG8gd291bGQgYXNzaWduIHRoZSBjb25maWRlbmNlIHZhbHVlPyAgSWYgaXQn cyBhc3NpZ25lZCBieSB0aGUgZW50aXR5IHRoYXQgb3BlcmF0ZXMgdGhlIGNhbGxpbmcgbmFtZSBk YXRhYmFzZSwgd2h5IHdvdWxkIGl0IGV2ZXIgYmUgbGVzcyB0aGFuIHRoZSBoaWdoZXN0IHBvc3Np YmxlIHZhbHVlPyAgSWYgaXQncyBzZXQgYnkgc29tZSBvdGhlciBlbnRpdHksIG9uIHdoYXQgYmFz aXMgZG8gdGhleSBkZXRlcm1pbmUgdGhlIHZhbHVlIHRoZXkgYXNzaWduPyAgSXQgc2VlbXMgbGlr ZSB3ZSdyZSBnb2luZyB0byBzdHVtYmxlIG92ZXIgYnVzaW5lc3MgaXNzdWVzLg0KPiANCj4gVGlt DQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY25pdCBbbWFp bHRvOmNuaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIFJvc2VuDQo+IFNl bnQ6IEZyaWRheSwgSnVuZSAxMiwgMjAxNSAxMToyOCBBTQ0KPiBUbzogUmljaGFyZCBTaG9ja2V5 DQo+IENjOiBwaGlsaXBwZS5mb3VxdWFydEBvcmFuZ2UuY29tOyBIZW5uaW5nIFNjaHVsenJpbm5l OyBjbml0QGlldGYub3JnOyANCj4gU3RlcGhlbiBGYXJyZWxsDQo+IFN1YmplY3Q6IFJlOiBbY25p dF0gQ05JVCBDaGFydGVyIGJhc2hpbmcuLg0KPiANCj4gT25lIHBvc3NpYmxlIGV4dHJhIGJpdCBp cyB0aGF0IHdlIG5lZWQgdG8ga25vdyBXSE8gc2lnbmVkLiAgVGhhdCBjb3VsZCBiZSBlYXN5IChp ZGVudGl0eSBpbiBhIGNlcnQgZm9yIHRoZSBzaWduYXR1cmUpLCBidXQgaXTigJlzIGEgcmVxdWly ZW1lbnQuDQo+IA0KPiBJIHN0aWxsIHdhbnQgYW4gb3B0aW9uYWwgY29uZmlkZW5jZSB2YWx1ZSwg YmVjYXVzZSB0aGUgc291cmNlIGlzIG9mdGVuIG5vdCBhdXRob3JpdGF0aXZlLg0KPiANCj4gSWYg d2XigJlyZSB0aGlua2luZyB3ZeKAmXJlIHVzaW5nIHRoZSBleGlzdGluZyBkaXNwbGF5IG5hbWUs IGFuZCBjb21pbmcgdXAgd2l0aCBhIHdheSB0byBzaWduIGl0LCB0aGVuLCBsaWtlIHN0aXIsIHRo ZSB0ZXJtaW5hdGlvbiBzaWRlIGNhbiBkZWNpZGUgd2hhdCBpdCB3YW50cyB0byBkbyBpZiBpdCBn ZXRzIGEgZGlzcGxheSBuYW1lIGJ1dCBubyBzaWduYXR1cmUuICBUaGUgc2VuZGVyIGhhcyB0aGUg b3B0aW9uIHRvIHByb3ZpZGUgdGhlIG5hbWUgb3Igbm90LCBhbmQgcHJvdmlkZSB0aGUgc2lnbmF0 dXJlIG9yIG5vdC4NCj4gDQo+IFdlIENPVUxEIGNvbnNpZGVyIGEgbmV3IGhlYWRlciB0aGF0IHdv dWxkIGNvbnRhaW4gdGhlIG5hbWUgZW5jcnlwdGVkIGZvciBhIGRlc3RpbmF0aW9uIFROIChUbzop LiAgVGhhdCB3b3VsZCBhZmZvcmQgcHJpdmFjeSB0byB0aGUgbmFtZSB0byBtaWRkbGUgYm94ZXMg dGhhdCB3ZSB3b3VsZCBub3QgaGF2ZSB0b2RheSB3aXRoIGRpc3BsYXkgbmFtZS4gIEkgd291bGQg bm90IGJlIG9wcG9zZWQgdG8gdGhhdC4gIFRoaXMgd291bGQgd29yayBsaWtlIHRoZSBvZmZsaW5l IHN0aXIgcHJvcG9zYWwsIHdoZXJlIHRoZSBzZW5kZXIgb2J0YWlucyB0aGUgcHVibGljIGtleSBv ZiB0aGUgcmVjaXBpZW50IGFuZCBlbmNyeXB0cyB0aGUgbmFtZSBmb3IgdGhlIHJlY2lwaWVudC4N Cj4gDQo+IEJyaWFuDQo+IA0KPj4gT24gSnVuIDEyLCAyMDE1LCBhdCA4OjQ5IEFNLCBSaWNoYXJk IFNob2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz4gd3JvdGU6DQo+PiANCj4+IA0KPj4gSGVubmlu ZyBpcyByaWdodC4gTm8gb25lIGlzIGZvcmNpbmcgYW55dGhpbmcuIEV4aXN0aW5nIGFub255bW91 cyANCj4+IGNhbGxpbmcgcHJvdGVjdGlvbnMgc3RpbGwgYXBwbHkuDQo+PiANCj4+IA0KPj4gQWdh aW4gbXkgcG9pbnQgaXMgdGhhdCBpcyBhIGdyZWF0IG1hbnkgY2FzZXMgSW50ZXJjb25uZWN0ZWQg U0lQIA0KPj4gYmV0d2VlbiBOQSBjYXJyaWVycyBhcmUgY292ZXJlZCBieSBvdGhlciBzZWN1cml0 eSBtZWNoYW5pc21zLg0KPj4gDQo+PiBSaWdodCBub3cgeW91ciBGYWNldGltZSBzZXNzaW9uIGlz IHRvdGFsbHkgaW4gdGhlIGNsZWFyLiBNeSBjb25jZXJuIA0KPj4gaXMgd2UgZW5kIHVwIGdvaW5n IGRvd24gdGhlIHJhdCBob2xlIG9mIHRyeWluZyB0byBjcmVhdGUgcGVyZmVjdCBlbmQgDQo+PiB0 byBlbmQgc2VjdXJpdHkgbm90aGluZyB3aWxsIGdldCBkb25lLg0KPj4gDQo+PiANCj4+IA0KPj4g T24gNi8xMi8xNSwgMTA6MTcgQU0sICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllPiB3cm90ZToNCj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9uIDEyLzA2LzE1IDE1OjEz LCBIZW5uaW5nIFNjaHVsenJpbm5lIHdyb3RlOg0KPj4+PiBJbiBhbG1vc3QgYWxsIGNhc2VzIG9m IGludGVyZXN0LCB0aGUgY2FsbGluZyBwYXJ0eSAqd2FudHMqIHRvIA0KPj4+PiBkaXNjbG9zZSBh Y2N1cmF0ZSBpbmZvcm1hdGlvbiB0byB0aGUgY2FsbGVkIHBhcnR5LCBzbyB0aGUgcHJpdmFjeSAN Cj4+Pj4gaXNzdWVzIGRvbid0IHNlZW0gdG8gYXJpc2UuIFRoZXkgd291bGQgb25seSBhcmlzZSBp ZiB0aGVyZSB3YXMgDQo+Pj4+IGZvcmNlZCBkaXNjbG9zdXJlOyBJIGRvbid0IHRoaW5rIGFueWJv ZHkgaXMgcHJvcG9zaW5nIHRoYXQuDQo+Pj4gDQo+Pj4gUHJpdmFjeSBpc3N1ZXMgY291bGQgYWxz byBhcmlzZSBpZiBhIG1pZGRsZWJveCBjb3VsZCBub3cgc2VlIA0KPj4+IHNlbnNpdGl2ZSBpbmZv cm1hdGlvbiB0aGF0IGl0IHByZXZpb3VzbHkgY291bGQgbm90IHNlZS4gSSB0aGluayB0aGF0IA0K Pj4+IGlzIGluZGVwZW5kZW50IG9mIHdoZXRoZXIgZGlzY2xvc3VyZSBpcyBkZXNpcmVkIGJ5IGVp dGhlciBvZiB0aGUgDQo+Pj4gZW5kcG9pbnRzLg0KPj4+IA0KPj4+IFMuDQo+Pj4gDQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBjbml0IG1h aWxpbmcgbGlzdA0KPj4+IGNuaXRAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NuaXQNCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gY25pdCBtYWlsaW5nIGxpc3QNCj4+IGNuaXRA aWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY25pdA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Y25pdCBtYWlsaW5nIGxpc3QNCj4gY25pdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NuaXQNCg0K From nobody Fri Jun 12 13:18:41 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0138C1AD074 for ; Fri, 12 Jun 2015 13:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNOGG9t1A853 for ; Fri, 12 Jun 2015 13:18:38 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 6A28D1AD01E for ; Fri, 12 Jun 2015 13:18:38 -0700 (PDT) Received: (qmail 28606 invoked by uid 0); 12 Jun 2015 20:18:35 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy5.mail.unifiedlayer.com with SMTP; 12 Jun 2015 20:18:35 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id fdrB1q0011MNPNq01drEt6; Fri, 12 Jun 2015 19:51:24 -0600 X-Authority-Analysis: v=2.1 cv=VOtOwb/X c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=ZsyXEVtvAAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=R6IWTHeYQwKbDX9W5BkA:9 a=4dWUvDMV7Zh_mHkK:21 a=sJGg5CuC1gQhcA9x:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=mnQx+/IxOyetsUokOUmTT9B+HLAcUftqsXVTw6HaRWk=; b=RgYPCdMSitwk54Tct4buS9W1euP/17ZWrIGbdqG0WCnZ9N6qXkCgINI+GinvOFcNRJeQiGVMm1HHZq5CUFFPIsm+1SVVdpGj6GdcRtAIaoW9lnoKP4eVUGEXr15sNnHN; Received: from [108.56.131.149] (port=52181 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z3V5p-0003RQ-Px; Fri, 12 Jun 2015 13:58:22 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Fri, 12 Jun 2015 15:58:16 -0400 From: Richard Shockey To: "Dwight, Timothy M (Tim)" , Stephen Farrell , Henning Schulzrinne , "philippe.fouquart@orange.com" , "cnit@ietf.org" Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <2B0F677F0B95454297753F58D4A07FA30279326B59@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30279326B59@FHDP1LUMXC7V31.us.one.verizon.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:18:40 -0000 On 6/12/15, 12:47 PM, "Dwight, Timothy M (Tim)" wrote: >Rich, > >I'm probably not following this right, so bear with me. In the current >paradigm the calling party's name isn't sent in the call request message, >right?=20 You know how it works in SS7. If SIP is used the verbose CNAM (15 character ASCII) data can be carried in either the From field or P-A though its my understanding that P-A is typically preferred. There is another proposal we have seen that could carry the verbose data in CALL-INFO as well. > But you're proposing that it should be (or optionally could be, >whatever).=20 Could be.. > Doesn't that open up the possibility Mr. Farrell suggested, that some >entity that's in the path of the call request message can "see" something >he previously could not? Possibly if normal BGP routing is done vs big yellow fiber optic cable. There are multiple interconnection models here some use classic IP routing others don=B9t. The use case I would want to protect is the one where the security layer is lower on the stack or the reference to A-CNAM or PII would be by URI reference where the originating SP could apply normal HTTPS security mechanism for retrieval etc. This would certainly apply to the 7095 JSON vcard object. > >Note that "existing anonymous calling protections" apply to the >presentation of information to the user, not necessarily to carriage of >information across the network. The FROM header may be anonymized when >the calling user requests privacy, for example, but the >P-Asserted-Identity header will not Yes but that is a policy issue that needs to be worked out. >. So if we were to use the display name in the P-A-ID to carry the >calling party name asserted by the originating network, that name would >(unless we encrypt it) be "visible" to any network element on the path of >the INVITE. =20 Or available by reference as the terminating SBC does the look up =8Aoh between the first and second ring :-) > >tim > > >-----Original Message----- >From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey >Sent: Friday, June 12, 2015 10:50 AM >To: Stephen Farrell; Henning Schulzrinne; philippe.fouquart@orange.com; >cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > > >Henning is right. No one is forcing anything. Existing anonymous calling >protections still apply. > > >Again my point is that is a great many cases Interconnected SIP between >NA carriers are covered by other security mechanisms. > >Right now your Facetime session is totally in the clear. My concern is we >end up going down the rat hole of trying to create perfect end to end >security nothing will get done. > > > >On 6/12/15, 10:17 AM, "Stephen Farrell" wrote: > >> >> >>On 12/06/15 15:13, Henning Schulzrinne wrote: >>> In almost all cases of interest, the calling party *wants* to >>> disclose accurate information to the called party, so the privacy >>> issues don't seem to arise. They would only arise if there was forced >>> disclosure; I don't think anybody is proposing that. >> >>Privacy issues could also arise if a middlebox could now see sensitive >>information that it previously could not see. I think that is >>independent of whether disclosure is desired by either of the >>endpoints. >> >>S. >> >>_______________________________________________ >>cnit mailing list >>cnit@ietf.org >>https://www.ietf.org/mailman/listinfo/cnit > > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit From nobody Fri Jun 12 14:42:47 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DC01B2B44 for ; Fri, 12 Jun 2015 14:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_cFyLH0UPqM for ; Fri, 12 Jun 2015 14:42:36 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 8CD311B2AF8 for ; Fri, 12 Jun 2015 14:42:36 -0700 (PDT) Received: (qmail 23256 invoked by uid 0); 12 Jun 2015 21:42:34 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy1.mail.unifiedlayer.com with SMTP; 12 Jun 2015 21:42:34 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id fZC81q00M1MNPNq01ZCBPN; Fri, 12 Jun 2015 15:12:13 -0600 X-Authority-Analysis: v=2.1 cv=GeGEw2nL c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=ZsyXEVtvAAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=N-o-GFsCB7nXL0PJcZYA:9 a=L4t86ZUlS2-xI8Jf:21 a=GWvnqYzpQXeMEOCQ:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=rygIzk6pMvb0WqrtUKupcJt/SrjhjWxgmpgjDMvYa8A=; b=nsfaKvrZ5vzhXjlobiukpfsJdKd1fOQEMO5CVpemgUTdRdDOozRm4KHE5imibwzoCbU8GniL0GrIzGaAgTf95UAg/5GsYDx0CUkjQo3MzuNF2ASCxoszk67y+Q9PIT35; Received: from [108.56.131.149] (port=52257 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z3WPF-0005dT-Bp; Fri, 12 Jun 2015 15:22:29 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Fri, 12 Jun 2015 17:22:25 -0400 From: Richard Shockey To: "Dwight, Timothy M (Tim)" , Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326D6D@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30279326D6D@FHDP1LUMXC7V31.us.one.verizon.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 21:42:39 -0000 Yes Tim. Thank you very very much. You cut to the chase of the problem here. Its not technology its policy and no matter how you end up looking at this its National Policy. KISS I just want to define the CNIT object and SIP headers and NOTHING ELSE. IF this should progress in the IETF that needs to be understood. That said and this is not the carrier business case mailing list. We all know the problem has advanced to the point of degrading the value proposition of the realtime communications service in North America. I=E2=80=99ve argued endlessly in talks that =E2=80=9CProtect what you have=E2=80=9D makes sense and = as Henning correctly points out there is a business case for adding value here to SIP based realtime communications across all the access platforms including VoLTE and definitely enterprise and there is a real and important Public Safety component here as well. We know how this should work. My Doctor wants to talk to me ASAP about my medical test results. She wants to display to me that she is exactly who she says she is and that should be possible so I don=E2=80=99t instantly drop the call to voice mail or worse. Her office is served by VZ my mobile is served by ATT. My ATT VoLTE CUA should be able to trust=E2=80=A6by multiple means (including big yellow optical cable) that the INVITE is actually coming from VZ. I see some data on my phone etc I run out of what ever room I=E2=80=99m in and take the call because I trust the SIP session. BTW this is equally relevant if the call is initiated by Fairfax County Public safety. We are trying to protect a 150+ Billion dollar business for SP=E2=80=99s which represents voice across all the access platforms. I=E2=80=99m not going to suppor= t third party business issues. We all want point to point video and it can work if we can display who the heck is calling. OTT is not a issue. Believe me. Get the Telegeography data on OTT penetration in NA and its stunning once N America went to near flat rate on voice the threat subsided. OK margins got shot but so did OPEX on transport. Our European friends are totally insane. They are still addicted to the drug of calling party pays and insane translation costs then whine to the EU Commission about WhatsAPP etc. They need rehab. That said our Congresscritter friends are one bunch of pissed off puppies and at some point they will do some really really stupid if we don=E2=80=99t come up with a plan.=20 On 6/12/15, 4:42 PM, "Dwight, Timothy M (Tim)" wrote: >Yes, it's a business issue. Brian wants the protocols to allow him to >insert an unverifiable advertisement that his data is "good". > >If allowing this moves us forward, fine. There's always some noise in >the system. But if this becomes a big topic of debate we need to take it >out. It's clearly not essential, and probably not even useful. > >Tim > > >-----Original Message----- >From: Richard Shockey [mailto:richard@shockey.us] >Sent: Friday, June 12, 2015 3:01 PM >To: Dwight, Timothy M (Tim) >Subject: Re: [cnit] CNIT Charter bashing.. > > > >On 6/12/15, 12:56 PM, "Dwight, Timothy M (Tim)" > wrote: > >>Who would assign the confidence value? > >Tinker bell=C5=A0.the tooth fairy. :-) > >This could get really ugly and spawn endless lawsuits but its a >reasonable idea if someone has a appropriate bayesian algorithm to apply >to this at the terminating SBC. > > >>If it's assigned by the entity that operates the calling name database, >>why would it ever be less than the highest possible value? If it's set >>by some other entity, on what basis do they determine the value they >>assign? It seems like we're going to stumble over business issues. >> >>Tim >> >> >>-----Original Message----- >>From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen >>Sent: Friday, June 12, 2015 11:28 AM >>To: Richard Shockey >>Cc: philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org; >>Stephen Farrell >>Subject: Re: [cnit] CNIT Charter bashing.. >> >>One possible extra bit is that we need to know WHO signed. That could >>be easy (identity in a cert for the signature), but it=C2=B9s a requirement. >> >>I still want an optional confidence value, because the source is often >>not authoritative. >> >>If we=C2=B9re thinking we=C2=B9re using the existing display name, and coming up >>with a way to sign it, then, like stir, the termination side can decide >>what it wants to do if it gets a display name but no signature. The >>sender has the option to provide the name or not, and provide the >>signature or not. >> >>We COULD consider a new header that would contain the name encrypted >>for a destination TN (To:). That would afford privacy to the name to >>middle boxes that we would not have today with display name. I would >>not be opposed to that. This would work like the offline stir >>proposal, where the sender obtains the public key of the recipient and >>encrypts the name for the recipient. >> >>Brian >> >>> On Jun 12, 2015, at 8:49 AM, Richard Shockey >>>wrote: >>>=20 >>>=20 >>> Henning is right. No one is forcing anything. Existing anonymous >>> calling protections still apply. >>>=20 >>>=20 >>> Again my point is that is a great many cases Interconnected SIP >>> between NA carriers are covered by other security mechanisms. >>>=20 >>> Right now your Facetime session is totally in the clear. My concern >>> is we end up going down the rat hole of trying to create perfect end >>> to end security nothing will get done. >>>=20 >>>=20 >>>=20 >>> On 6/12/15, 10:17 AM, "Stephen Farrell" >>>wrote: >>>=20 >>>>=20 >>>>=20 >>>> On 12/06/15 15:13, Henning Schulzrinne wrote: >>>>> In almost all cases of interest, the calling party *wants* to >>>>> disclose accurate information to the called party, so the privacy >>>>> issues don't seem to arise. They would only arise if there was >>>>> forced disclosure; I don't think anybody is proposing that. >>>>=20 >>>> Privacy issues could also arise if a middlebox could now see >>>> sensitive information that it previously could not see. I think that >>>> is independent of whether disclosure is desired by either of the >>>> endpoints. >>>>=20 >>>> S. >>>>=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 nobody Fri Jun 12 15:28:32 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F34D1A92E9 for ; Fri, 12 Jun 2015 15:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZgHHWD88aHt for ; Fri, 12 Jun 2015 15:28:28 -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 91B2E1B2BB0 for ; Fri, 12 Jun 2015 15:28:28 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" , Brian Rosen Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3t Date: Fri, 12 Jun 2015 22:28:25 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net>, <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30279326CB7@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "philippe.fouquart@orange.com" , "cnit@ietf.org" , Stephen Farrell , Richard Shockey Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 22:28:31 -0000 Today's CNAM display has three problems:=0A= =0A= (1) It is unclear to the recipient how the data got inserted and by whom. T= here is no realistic way for the callee to find out - good luck calling you= r phone company consumer support line and asking about CNAM database dips.= =0A= =0A= (2) The caller has no idea what will be shown to any given called party - d= epending on the destination CNAM service, it could be the correct name, not= hing, just "Florida", or maybe the name of the person who had the same numb= er six months ago and hopefully didn't sell adult entertainment.=0A= =0A= (3) For some numbers, bad actors can insert any random information they cho= ose, again with problem #1.=0A= =0A= Even unsigned SIP display or Call-Info information, with some modicum of co= mmon behavior among carriers, will address all three problems, even if not = perfectly, then most of the time. I may have no idea what validation Verizo= n uses to assure that their customers are indeed John Smith, but at least I= know that I can tell who created the entry. A lawyer will know where to ad= dress the cease&desist letter if needed.=0A= =0A= ________________________________________=0A= From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]=0A= Sent: Friday, June 12, 2015 3:21 PM=0A= To: Brian Rosen=0A= Cc: Richard Shockey; philippe.fouquart@orange.com; Henning Schulzrinne; cni= t@ietf.org; Stephen Farrell=0A= Subject: RE: [cnit] CNIT Charter bashing..=0A= =0A= I guess as long as the derivation of the name (who is asserting it to be a = valid representation of the caller, and from where did they get it) is clea= r to the receiving network, I guess this is OK. I still have my doubts whe= ther such a value will prove useful, given that its computation is not stan= dardized. But in some contexts, it might.=0A= =0A= Tim=0A= =0A= =0A= -----Original Message-----=0A= From: Brian Rosen [mailto:br@brianrosen.net]=0A= Sent: Friday, June 12, 2015 12:51 PM=0A= To: Dwight, Timothy M (Tim)=0A= Cc: Richard Shockey; philippe.fouquart@orange.com; Henning Schulzrinne; cni= t@ietf.org; Stephen Farrell=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= Yes, it would be assigned by the entity that signed the name.=0A= =0A= It=92s not true that it would always be the highest possible value. If the= entity that provided it did that, the receiving entity might not believe i= t, and choose to use an alternative name source (or at least check another = service to see what it thought). Modern systems that collect names subject= user data with verification sources that are getting very accurate, but th= ose services have scoring systems that don=92t result in black/white result= s. Older systems blithely accept whatever the customer says, and those are= not accurate. Some services have something simpler, like the name has to = match a credit card name, but we know those are pretty spoofable these days= . Real systems use external verification services that provide scores for = this kind of thing.=0A= =0A= I=92m simply proposing that we allow an optional confidence, in the range o= f 0-100, and that it be part of the data signed by the data provider. No o= ne has to send it, no one has to look at it. But it represents what is sta= te of the art these days on asserting names and I think it=92s valuable.=0A= =0A= Brian=0A= > On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) wrote:=0A= >=0A= > Who would assign the confidence value? If it's assigned by the entity th= at operates the calling name database, why would it ever be less than the h= ighest possible value? If it's set by some other entity, on what basis do = they determine the value they assign? It seems like we're going to stumble= over business issues.=0A= >=0A= > Tim=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen=0A= > Sent: Friday, June 12, 2015 11:28 AM=0A= > To: Richard Shockey=0A= > Cc: philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org;=0A= > Stephen Farrell=0A= > Subject: Re: [cnit] CNIT Charter bashing..=0A= >=0A= > One possible extra bit is that we need to know WHO signed. That could be= easy (identity in a cert for the signature), but it=92s a requirement.=0A= >=0A= > I still want an optional confidence value, because the source is often no= t authoritative.=0A= >=0A= > If we=92re thinking we=92re using the existing display name, and coming u= p with a way to sign it, then, like stir, the termination side can decide w= hat it wants to do if it gets a display name but no signature. The sender = has the option to provide the name or not, and provide the signature or not= .=0A= >=0A= > We COULD consider a new header that would contain the name encrypted for = a destination TN (To:). That would afford privacy to the name to middle bo= xes that we would not have today with display name. I would not be opposed= to that. This would work like the offline stir proposal, where the sender= obtains the public key of the recipient and encrypts the name for the reci= pient.=0A= >=0A= > Brian=0A= >=0A= >> On Jun 12, 2015, at 8:49 AM, Richard Shockey wrote:= =0A= >>=0A= >>=0A= >> Henning is right. No one is forcing anything. Existing anonymous=0A= >> calling protections still apply.=0A= >>=0A= >>=0A= >> Again my point is that is a great many cases Interconnected SIP=0A= >> between NA carriers are covered by other security mechanisms.=0A= >>=0A= >> Right now your Facetime session is totally in the clear. My concern=0A= >> is we end up going down the rat hole of trying to create perfect end=0A= >> to end security nothing will get done.=0A= >>=0A= >>=0A= >>=0A= >> On 6/12/15, 10:17 AM, "Stephen Farrell" wrot= e:=0A= >>=0A= >>>=0A= >>>=0A= >>> On 12/06/15 15:13, Henning Schulzrinne wrote:=0A= >>>> In almost all cases of interest, the calling party *wants* to=0A= >>>> disclose accurate information to the called party, so the privacy=0A= >>>> issues don't seem to arise. They would only arise if there was=0A= >>>> forced disclosure; I don't think anybody is proposing that.=0A= >>>=0A= >>> Privacy issues could also arise if a middlebox could now see=0A= >>> sensitive information that it previously could not see. I think that=0A= >>> is independent of whether disclosure is desired by either of the=0A= >>> endpoints.=0A= >>>=0A= >>> S.=0A= >>>=0A= >>> _______________________________________________=0A= >>> cnit mailing list=0A= >>> cnit@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/cnit=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> cnit mailing list=0A= >> cnit@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/cnit=0A= >=0A= > _______________________________________________=0A= > cnit mailing list=0A= > cnit@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= From nobody Fri Jun 12 15:39:32 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940031B2B90 for ; Fri, 12 Jun 2015 15:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSIFiumTrdgB for ; Fri, 12 Jun 2015 15:39:27 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 123D91B2B66 for ; Fri, 12 Jun 2015 15:39:26 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Brian Rosen Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAAAqQYw== Date: Fri, 12 Jun 2015 22:39:26 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com>, <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> In-Reply-To: <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 22:39:30 -0000 We have gone around that issue a few times, I think. Without trying to reha= sh the arguments, I think the value is completely meaningless to the recipi= ent. The value is currently used within a closed environment - company A us= es a validation service V and presumably gets a good sense of what "70" mea= ns and whether that value is sufficiently high to do whatever they need to = do (extend credit, open an account, show tax return information). When comp= any B receives this information, it is completely meaningless to that recip= ient, as the value will depend on what information the customer A provided,= whether A used V, W or X for validation and when this information was vali= dated. Does 70 mean that 70% of the customers with that type of information= are indeed who they claim to be? Or just that the person answered 7 out of= 10 questions correctly?=0A= =0A= Thus, this information is meant to be interpreted within a particular conte= xt, and taking it out of this context renders it meaningless.=0A= =0A= Thus, unless these issues can be addressed, we would be conveying informati= on that pretends to be accurate, but is just noise. Brian, you repeat the s= ame idea, but never address the issues that get raised again and again. Thi= s is not helpful.=0A= =0A= We also now know from the IRS tax return debacle that knowledge-based authe= ntication varies in quality. I'm sure whoever got access to the tax returns= scored a 100 on whatever questions the web site asked...=0A= =0A= ________________________________________=0A= From: Brian Rosen [br@brianrosen.net]=0A= Sent: Friday, June 12, 2015 1:51 PM=0A= To: Dwight, Timothy M (Tim)=0A= Cc: Richard Shockey; philippe.fouquart@orange.com; Henning Schulzrinne; cni= t@ietf.org; Stephen Farrell=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= Yes, it would be assigned by the entity that signed the name.=0A= =0A= It=92s not true that it would always be the highest possible value. If the= entity that provided it did that, the receiving entity might not believe i= t, and choose to use an alternative name source (or at least check another = service to see what it thought). Modern systems that collect names subject= user data with verification sources that are getting very accurate, but th= ose services have scoring systems that don=92t result in black/white result= s. Older systems blithely accept whatever the customer says, and those are= not accurate. Some services have something simpler, like the name has to = match a credit card name, but we know those are pretty spoofable these days= . Real systems use external verification services that provide scores for = this kind of thing.=0A= =0A= I=92m simply proposing that we allow an optional confidence, in the range o= f 0-100, and that it be part of the data signed by the data provider. No o= ne has to send it, no one has to look at it. But it represents what is sta= te of the art these days on asserting names and I think it=92s valuable.=0A= =0A= Brian=0A= > On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) wrote:=0A= >=0A= > Who would assign the confidence value? If it's assigned by the entity th= at operates the calling name database, why would it ever be less than the h= ighest possible value? If it's set by some other entity, on what basis do = they determine the value they assign? It seems like we're going to stumble= over business issues.=0A= >=0A= > Tim=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen=0A= > Sent: Friday, June 12, 2015 11:28 AM=0A= > To: Richard Shockey=0A= > Cc: philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org; Ste= phen Farrell=0A= > Subject: Re: [cnit] CNIT Charter bashing..=0A= >=0A= > One possible extra bit is that we need to know WHO signed. That could be= easy (identity in a cert for the signature), but it=92s a requirement.=0A= >=0A= > I still want an optional confidence value, because the source is often no= t authoritative.=0A= >=0A= > If we=92re thinking we=92re using the existing display name, and coming u= p with a way to sign it, then, like stir, the termination side can decide w= hat it wants to do if it gets a display name but no signature. The sender = has the option to provide the name or not, and provide the signature or not= .=0A= >=0A= > We COULD consider a new header that would contain the name encrypted for = a destination TN (To:). That would afford privacy to the name to middle bo= xes that we would not have today with display name. I would not be opposed= to that. This would work like the offline stir proposal, where the sender= obtains the public key of the recipient and encrypts the name for the reci= pient.=0A= >=0A= > Brian=0A= >=0A= >> On Jun 12, 2015, at 8:49 AM, Richard Shockey wrote:= =0A= >>=0A= >>=0A= >> Henning is right. No one is forcing anything. Existing anonymous=0A= >> calling protections still apply.=0A= >>=0A= >>=0A= >> Again my point is that is a great many cases Interconnected SIP=0A= >> between NA carriers are covered by other security mechanisms.=0A= >>=0A= >> Right now your Facetime session is totally in the clear. My concern is= =0A= >> we end up going down the rat hole of trying to create perfect end to=0A= >> end security nothing will get done.=0A= >>=0A= >>=0A= >>=0A= >> On 6/12/15, 10:17 AM, "Stephen Farrell" wrot= e:=0A= >>=0A= >>>=0A= >>>=0A= >>> On 12/06/15 15:13, Henning Schulzrinne wrote:=0A= >>>> In almost all cases of interest, the calling party *wants* to=0A= >>>> disclose accurate information to the called party, so the privacy=0A= >>>> issues don't seem to arise. They would only arise if there was=0A= >>>> forced disclosure; I don't think anybody is proposing that.=0A= >>>=0A= >>> Privacy issues could also arise if a middlebox could now see=0A= >>> sensitive information that it previously could not see. I think that=0A= >>> is independent of whether disclosure is desired by either of the=0A= >>> endpoints.=0A= >>>=0A= >>> S.=0A= >>>=0A= >>> _______________________________________________=0A= >>> cnit mailing list=0A= >>> cnit@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/cnit=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> cnit mailing list=0A= >> cnit@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/cnit=0A= >=0A= > _______________________________________________=0A= > cnit mailing list=0A= > cnit@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= =0A= From nobody Fri Jun 12 15:48:01 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DC21A1A1C for ; Fri, 12 Jun 2015 15:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_kOgL8M6mw6 for ; Fri, 12 Jun 2015 15:47:58 -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 378301A1A3D for ; Fri, 12 Jun 2015 15:47:58 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" , "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAABA5AIAAH5PP Date: Fri, 12 Jun 2015 22:47:56 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> , <2B0F677F0B95454297753F58D4A07FA30279326B59@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30279326B59@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 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 22:48:00 -0000 I suspect there could be cases where a caller objects to the disclosure to = intermediate entities; they clearly should have the option of not including= the name information, either on a call-by-call or global basis. I'm guessi= ng that this is a rare case; for the entities most reliant on caller name i= nformation, namely entities that cannot count on being in the address book = of the called party, they usually have semi-public telephone numbers, so th= at the mapping to the name is essentially public. As I noted, as long as ro= ughly the same information is in-band as out-of-band today, every single ca= rrier can already look up CNAM information if they are so inclined. Thus, I= 'm not quite following how this makes things worse. (The difference is that= today, I can look up CNAM information for any phone number, even if the en= tity never called me. In-band delivery would obviate the need for CNAM data= bases, so it would seem to make things better, not worse.)=0A= =0A= The latter point obviously only applies to countries with CNAM; as long as = the opt-in/opt-out nature is preserved, this seems more like a disclosure i= ssue ("your name is visible to your carrier and, if the carrier is too lazy= to implement SIP over TLS, any national intelligence agency that happens t= o be watching that fiber").=0A= =0A= ________________________________________=0A= From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]=0A= Sent: Friday, June 12, 2015 12:47 PM=0A= To: Richard Shockey; Stephen Farrell; Henning Schulzrinne; philippe.fouquar= t@orange.com; cnit@ietf.org=0A= Subject: RE: [cnit] CNIT Charter bashing..=0A= =0A= Rich,=0A= =0A= I'm probably not following this right, so bear with me. In the current par= adigm the calling party's name isn't sent in the call request message, righ= t? But you're proposing that it should be (or optionally could be, whateve= r). Doesn't that open up the possibility Mr. Farrell suggested, that some = entity that's in the path of the call request message can "see" something h= e previously could not?=0A= =0A= Note that "existing anonymous calling protections" apply to the presentatio= n of information to the user, not necessarily to carriage of information ac= ross the network. The FROM header may be anonymized when the calling user = requests privacy, for example, but the P-Asserted-Identity header will not.= So if we were to use the display name in the P-A-ID to carry the calling = party name asserted by the originating network, that name would (unless we = encrypt it) be "visible" to any network element on the path of the INVITE.= =0A= =0A= tim=0A= =0A= =0A= -----Original Message-----=0A= From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey=0A= Sent: Friday, June 12, 2015 10:50 AM=0A= To: Stephen Farrell; Henning Schulzrinne; philippe.fouquart@orange.com; cni= t@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= =0A= Henning is right. No one is forcing anything. Existing anonymous calling pr= otections still apply.=0A= =0A= =0A= Again my point is that is a great many cases Interconnected SIP between NA = carriers are covered by other security mechanisms.=0A= =0A= Right now your Facetime session is totally in the clear. My concern is we e= nd up going down the rat hole of trying to create perfect end to end securi= ty nothing will get done.=0A= =0A= =0A= =0A= On 6/12/15, 10:17 AM, "Stephen Farrell" wrote:= =0A= =0A= >=0A= >=0A= >On 12/06/15 15:13, Henning Schulzrinne wrote:=0A= >> In almost all cases of interest, the calling party *wants* to=0A= >> disclose accurate information to the called party, so the privacy=0A= >> issues don't seem to arise. They would only arise if there was forced=0A= >> disclosure; I don't think anybody is proposing that.=0A= >=0A= >Privacy issues could also arise if a middlebox could now see sensitive=0A= >information that it previously could not see. I think that is=0A= >independent of whether disclosure is desired by either of the=0A= >endpoints.=0A= >=0A= >S.=0A= >=0A= >_______________________________________________=0A= >cnit mailing list=0A= >cnit@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= =0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= From nobody Fri Jun 12 15:51:18 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E366F1A1AA2 for ; Fri, 12 Jun 2015 15:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjz-gamxYJ3Y for ; Fri, 12 Jun 2015 15:51:16 -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 87ECD1A1A55 for ; Fri, 12 Jun 2015 15:51:16 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Brian Rosen Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAJydF Date: Fri, 12 Jun 2015 22:51:15 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> , <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> In-Reply-To: <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "philippe.fouquart@orange.com" , "cnit@ietf.org" , Stephen Farrell Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 22:51:18 -0000 Once numbers have public (STIR) keys, the sender should indeed be able to e= ncrypt the information without creating a new infrastructure for distributi= ng keys, and the destination carrier can decrypt. (I think I'm just amplify= ing slightly what you are saying, not disagreeing.)=0A= =0A= Agreed on "who", although this may be implicit in some cases (e.g., if sign= ed by the number-signing entity).=0A= =0A= ________________________________________=0A= From: Brian Rosen [br@brianrosen.net]=0A= Sent: Friday, June 12, 2015 12:28 PM=0A= To: Richard Shockey=0A= Cc: Stephen Farrell; Henning Schulzrinne; philippe.fouquart@orange.com; cni= t@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= One possible extra bit is that we need to know WHO signed. That could be e= asy (identity in a cert for the signature), but it=92s a requirement.=0A= =0A= I still want an optional confidence value, because the source is often not = authoritative.=0A= =0A= If we=92re thinking we=92re using the existing display name, and coming up = with a way to sign it, then, like stir, the termination side can decide wha= t it wants to do if it gets a display name but no signature. The sender ha= s the option to provide the name or not, and provide the signature or not.= =0A= =0A= We COULD consider a new header that would contain the name encrypted for a = destination TN (To:). That would afford privacy to the name to middle boxe= s that we would not have today with display name. I would not be opposed t= o that. This would work like the offline stir proposal, where the sender o= btains the public key of the recipient and encrypts the name for the recipi= ent.=0A= =0A= Brian=0A= =0A= From nobody Fri Jun 12 16:21:09 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD951A8788 for ; Fri, 12 Jun 2015 16:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a3KGjvmKSUp for ; Fri, 12 Jun 2015 16:21:04 -0700 (PDT) Received: from mail-vn0-f54.google.com (mail-vn0-f54.google.com [209.85.216.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636CF1A8791 for ; Fri, 12 Jun 2015 16:21:04 -0700 (PDT) Received: by vnbf7 with SMTP id f7so8276020vnb.13 for ; Fri, 12 Jun 2015 16:21:03 -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=N22gIoHQieOdHd/5FSCNhRz5RtVyKTmBljSGyd08BG0=; b=Vwvwte5pqVmKv6NCtEHLs9vYHzrND2XEwx/NhVasEP9WheIB3ggUKWKOandvfA2ZhG EpwhPcJmn1EdU4ZAQa+w2w9nWzIMfvXQL3Hr0FKNl8mYLtJ/CHqbgvRKqNrvMyc8x9ml UaopRcSDASx49BX27dMOzqcz0Xt88NC4DZnkmdLER9jEdnHpa3/Tu/6iW2ix0MF3FGWs J/uALHxSE+LKCZDKMT1ODerpTTGiFgeRHKfZsJRO1gOYk7VmaHQtMmYRDlkQiiJL2Ek6 0xZ5BAtHoedZw3WXfLcPwzUiwNJOx5h1+SjBD1RwxbFmId7MCXYrLp6/ZOjJixedEZKJ ULlQ== X-Gm-Message-State: ALoCoQlOFHNssI4S/IZDovmm59D6F5+uo9vVhhn/Qhuys5YCCk6cBclXckI07Z66ETELgPqXnbXk X-Received: by 10.52.90.42 with SMTP id bt10mr30148689vdb.13.1434151263589; Fri, 12 Jun 2015 16:21:03 -0700 (PDT) Received: from [10.33.128.56] ([156.154.61.4]) by mx.google.com with ESMTPSA id jk10sm6141571vdb.13.2015.06.12.16.21.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 16:21:02 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Brian Rosen In-Reply-To: Date: Fri, 12 Jun 2015 16:20:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <31D54523-375B-42D6-A621-28A009E2DF20@brianrosen.net> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 23:21:07 -0000 Okay so, I=92ll try to give you meaningful answers to the questions you = raise. I believe I=92ve done this before. > On Jun 12, 2015, at 3:39 PM, Henning Schulzrinne = wrote: >=20 > We have gone around that issue a few times, I think. Without trying to = rehash the arguments, I think the value is completely meaningless to the = recipient. The value is currently used within a closed environment - = company A uses a validation service V and presumably gets a good sense = of what "70" means and whether that value is sufficiently high to do = whatever they need to do (extend credit, open an account, show tax = return information). Actually, many companies have multiple sources of information, and use = more than one of them some times. Since there is zero standardization, = the company has to know how to interpret the results, but since there = are a relatively small number of sources, it works fine. When dealing = with a simple score, you have some kind of a scaling factor that = normalizes them. That idea will work just fine here. The receiving end = will have scaling factors for the sources it encounters. There may even = be services that provide scaling factors. You accumulate and adjust = your scaling factors based on the observations you have on the data. = Here, it might be customer complaints, or UIs that have =93report = errors=94 buttons, or periodic secondary validation systems. My company = could pretty easily calculate a pretty good set of scaling factors given = a large enough sample of historical call data with scores based on the = databases we have. So can others. If a new scoring service shows up, = it might have a pretty low scaling factor until you build up enough data = to raise it. =20 So the termination SP, or device, will apply a scale to the score based = on the identity of the source of the score and use that to determine = what to do. Depending on the device, it could change the appearance of = the name depending on the scaled score, or it could subject the name to = alternative validation, or use a third party name source. > When company B receives this information, it is completely meaningless = to that recipient, as the value will depend on what information the = customer A provided, whether A used V, W or X for validation and when = this information was validated. Does 70 mean that 70% of the customers = with that type of information are indeed who they claim to be? Or just = that the person answered 7 out of 10 questions correctly? The score can be defined as a confidence percentage. 70 means there is = a 70% chance the name is correct. The scoring service is free to use = any method it wants to come up with the score. =20 >=20 > Thus, this information is meant to be interpreted within a particular = context, and taking it out of this context renders it meaningless. The context is very well defined - what is the name of the entity = placing the call? The score is the confidence we have in the answer = provided. >=20 > Thus, unless these issues can be addressed, we would be conveying = information that pretends to be accurate, but is just noise. Brian, you = repeat the same idea, but never address the issues that get raised again = and again. This is not helpful. No, it=92s the exact opposite. When you send just a name without a = score, you are pretending it=92s 100% accurate, and that is clearly = wrong. When you send a score, you acknowledge that the data is not 100% = accurate, and you show what your confidence is in the information you = are providing. Since we have a lot of experience, we know how to get = quality scoring. What we can=92t do is mandate a good scoring = methodology or source, so we have to have some more complications like = the scaling factor. But we do that now, because there is lots of = competition for data, having more than one source is common and yet we = know they don=92t all provide the same quality of data. So we deal with = that. >=20 > We also now know from the IRS tax return debacle that knowledge-based = authentication varies in quality. I'm sure whoever got access to the tax = returns scored a 100 on whatever questions the web site asked=85 Certainly. Any scoring system can be gamed. Nothing is perfect. But = just saying the guy=92s name is Clark Kent is no where near as useful as = saying that Name Scoring Service Inc says there is an 93% probability = that the guy=92s name is Clark Kent. If someone says 100%, you should = not believe them. These kinds of systems are common. We use them in lots of environments. = We know how they work. We know what their limitations are. This isn=92t= rocket science, but it is data science. Why are you so skeptical of = proven systems? Brian >=20 > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Friday, June 12, 2015 1:51 PM > To: Dwight, Timothy M (Tim) > Cc: Richard Shockey; philippe.fouquart@orange.com; Henning = Schulzrinne; cnit@ietf.org; Stephen Farrell > Subject: Re: [cnit] CNIT Charter bashing.. >=20 > Yes, it would be assigned by the entity that signed the name. >=20 > It=92s not true that it would always be the highest possible value. = If the entity that provided it did that, the receiving entity might not = believe it, and choose to use an alternative name source (or at least = check another service to see what it thought). Modern systems that = collect names subject user data with verification sources that are = getting very accurate, but those services have scoring systems that = don=92t result in black/white results. Older systems blithely accept = whatever the customer says, and those are not accurate. Some services = have something simpler, like the name has to match a credit card name, = but we know those are pretty spoofable these days. Real systems use = external verification services that provide scores for this kind of = thing. >=20 > I=92m simply proposing that we allow an optional confidence, in the = range of 0-100, and that it be part of the data signed by the data = provider. No one has to send it, no one has to look at it. But it = represents what is state of the art these days on asserting names and I = think it=92s valuable. >=20 > Brian >> On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) = wrote: >>=20 >> Who would assign the confidence value? If it's assigned by the = entity that operates the calling name database, why would it ever be = less than the highest possible value? If it's set by some other entity, = on what basis do they determine the value they assign? It seems like = we're going to stumble over business issues. >>=20 >> Tim >>=20 >>=20 >> -----Original Message----- >> From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen >> Sent: Friday, June 12, 2015 11:28 AM >> To: Richard Shockey >> Cc: philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org; = Stephen Farrell >> Subject: Re: [cnit] CNIT Charter bashing.. >>=20 >> One possible extra bit is that we need to know WHO signed. That = could be easy (identity in a cert for the signature), but it=92s a = requirement. >>=20 >> I still want an optional confidence value, because the source is = often not authoritative. >>=20 >> If we=92re thinking we=92re using the existing display name, and = coming up with a way to sign it, then, like stir, the termination side = can decide what it wants to do if it gets a display name but no = signature. The sender has the option to provide the name or not, and = provide the signature or not. >>=20 >> We COULD consider a new header that would contain the name encrypted = for a destination TN (To:). That would afford privacy to the name to = middle boxes that we would not have today with display name. I would = not be opposed to that. This would work like the offline stir proposal, = where the sender obtains the public key of the recipient and encrypts = the name for the recipient. >>=20 >> Brian >>=20 >>> On Jun 12, 2015, at 8:49 AM, Richard Shockey = wrote: >>>=20 >>>=20 >>> Henning is right. No one is forcing anything. Existing anonymous >>> calling protections still apply. >>>=20 >>>=20 >>> Again my point is that is a great many cases Interconnected SIP >>> between NA carriers are covered by other security mechanisms. >>>=20 >>> Right now your Facetime session is totally in the clear. My concern = is >>> we end up going down the rat hole of trying to create perfect end to >>> end security nothing will get done. >>>=20 >>>=20 >>>=20 >>> On 6/12/15, 10:17 AM, "Stephen Farrell" = wrote: >>>=20 >>>>=20 >>>>=20 >>>> On 12/06/15 15:13, Henning Schulzrinne wrote: >>>>> In almost all cases of interest, the calling party *wants* to >>>>> disclose accurate information to the called party, so the privacy >>>>> issues don't seem to arise. They would only arise if there was >>>>> forced disclosure; I don't think anybody is proposing that. >>>>=20 >>>> Privacy issues could also arise if a middlebox could now see >>>> sensitive information that it previously could not see. I think = that >>>> is independent of whether disclosure is desired by either of the >>>> endpoints. >>>>=20 >>>> S. >>>>=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 >=20 From nobody Fri Jun 12 18:49:57 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC791A89C7 for ; Fri, 12 Jun 2015 18:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRn5jhLpiaeO for ; Fri, 12 Jun 2015 18:49:53 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 3F4DA1A89F2 for ; Fri, 12 Jun 2015 18:49:53 -0700 (PDT) Received: (qmail 20927 invoked by uid 0); 13 Jun 2015 01:49:48 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy4.mail.unifiedlayer.com with SMTP; 13 Jun 2015 01:49:48 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id fjNj1q00Q1MNPNq01jNmfC; Sat, 13 Jun 2015 01:22:56 -0600 X-Authority-Analysis: v=2.1 cv=K/SxQUmI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=ZsyXEVtvAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8 a=-RqHiGeZdT-GHi7QhSwA:9 a=8tGa-5p59C2Tw4sx:21 a=d5IlJd9w4uSEENub:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=lIrvKle+btr31uh2rTVavoia4J6UDmrLst6oMweaFcc=; b=BRp14qG9gPnl+42U1b2tadAVZEMx8Xcxk5Ef7boAqhBbTCS07fqr4jxZdwGqARfSLFc2JkJr+LwGqWYVx1au/Tz6gxnMNmfMR6imwxgqmKcwoDFHfV/qkIUalXMDNbbv; Received: from [108.56.131.149] (port=52340 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z3aGN-0007jK-9J; Fri, 12 Jun 2015 19:29:35 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Fri, 12 Jun 2015 21:29:29 -0400 From: Richard Shockey To: Henning Schulzrinne , "Dwight, Timothy M (Tim)" , Brian Rosen Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Cc: "philippe.fouquart@orange.com" , Ben Campbell , Stephen Farrell , "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 01:49:56 -0000 Henning the biggest issue is that any form of advanced CNAM display is not currently applicable to the the mobile access devices. Which are now finally over 50% of the NANP even if you consider BYOD in the enterprise. Yea that is another use case. Hence the issue with Apple. This is ultimately a problem with that will have to be coordinated with US GSMA or GSMA generally. Or IMHO with the the 8th floor on 12th st. It really is a jawboning use. Tom needs to call Tim Cook or Larry Page and make the ask. I do reject Brians pretense here. Given the IETF context perfection is actually the enemy of deployment. I want a charter that is simple and clear. Header and object. Period. If that is impossible then =8A.. Its time the AD=B9s decide. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 6/12/15, 6:28 PM, "Henning Schulzrinne" wrote: >Today's CNAM display has three problems: > >(1) It is unclear to the recipient how the data got inserted and by whom. >There is no realistic way for the callee to find out - good luck calling >your phone company consumer support line and asking about CNAM database >dips. > >(2) The caller has no idea what will be shown to any given called party - >depending on the destination CNAM service, it could be the correct name, >nothing, just "Florida", or maybe the name of the person who had the same >number six months ago and hopefully didn't sell adult entertainment. > >(3) For some numbers, bad actors can insert any random information they >choose, again with problem #1. > >Even unsigned SIP display or Call-Info information, with some modicum of >common behavior among carriers, will address all three problems, even if >not perfectly, then most of the time. I may have no idea what validation >Verizon uses to assure that their customers are indeed John Smith, but at >least I know that I can tell who created the entry. A lawyer will know >where to address the cease&desist letter if needed. > >________________________________________ >From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] >Sent: Friday, June 12, 2015 3:21 PM >To: Brian Rosen >Cc: Richard Shockey; philippe.fouquart@orange.com; Henning Schulzrinne; >cnit@ietf.org; Stephen Farrell >Subject: RE: [cnit] CNIT Charter bashing.. > >I guess as long as the derivation of the name (who is asserting it to be >a valid representation of the caller, and from where did they get it) is >clear to the receiving network, I guess this is OK. I still have my >doubts whether such a value will prove useful, given that its computation >is not standardized. But in some contexts, it might. > >Tim > > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Friday, June 12, 2015 12:51 PM >To: Dwight, Timothy M (Tim) >Cc: Richard Shockey; philippe.fouquart@orange.com; Henning Schulzrinne; >cnit@ietf.org; Stephen Farrell >Subject: Re: [cnit] CNIT Charter bashing.. > >Yes, it would be assigned by the entity that signed the name. > >It=B9s not true that it would always be the highest possible value. If the >entity that provided it did that, the receiving entity might not believe >it, and choose to use an alternative name source (or at least check >another service to see what it thought). Modern systems that collect >names subject user data with verification sources that are getting very >accurate, but those services have scoring systems that don=B9t result in >black/white results. Older systems blithely accept whatever the customer >says, and those are not accurate. Some services have something simpler, >like the name has to match a credit card name, but we know those are >pretty spoofable these days. Real systems use external verification >services that provide scores for this kind of thing. > >I=B9m simply proposing that we allow an optional confidence, in the range >of 0-100, and that it be part of the data signed by the data provider. >No one has to send it, no one has to look at it. But it represents what >is state of the art these days on asserting names and I think it=B9s >valuable. > >Brian >> On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) >> wrote: >> >> Who would assign the confidence value? If it's assigned by the entity >>that operates the calling name database, why would it ever be less than >>the highest possible value? If it's set by some other entity, on what >>basis do they determine the value they assign? It seems like we're >>going to stumble over business issues. >> >> Tim >> >> >> -----Original Message----- >> From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen >> Sent: Friday, June 12, 2015 11:28 AM >> To: Richard Shockey >> Cc: philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org; >> Stephen Farrell >> Subject: Re: [cnit] CNIT Charter bashing.. >> >> One possible extra bit is that we need to know WHO signed. That could >>be easy (identity in a cert for the signature), but it=B9s a requirement. >> >> I still want an optional confidence value, because the source is often >>not authoritative. >> >> If we=B9re thinking we=B9re using the existing display name, and coming up >>with a way to sign it, then, like stir, the termination side can decide >>what it wants to do if it gets a display name but no signature. The >>sender has the option to provide the name or not, and provide the >>signature or not. >> >> We COULD consider a new header that would contain the name encrypted >>for a destination TN (To:). That would afford privacy to the name to >>middle boxes that we would not have today with display name. I would >>not be opposed to that. This would work like the offline stir proposal, >>where the sender obtains the public key of the recipient and encrypts >>the name for the recipient. >> >> Brian >> >>> On Jun 12, 2015, at 8:49 AM, Richard Shockey >>>wrote: >>> >>> >>> Henning is right. No one is forcing anything. Existing anonymous >>> calling protections still apply. >>> >>> >>> Again my point is that is a great many cases Interconnected SIP >>> between NA carriers are covered by other security mechanisms. >>> >>> Right now your Facetime session is totally in the clear. My concern >>> is we end up going down the rat hole of trying to create perfect end >>> to end security nothing will get done. >>> >>> >>> >>> On 6/12/15, 10:17 AM, "Stephen Farrell" >>>wrote: >>> >>>> >>>> >>>> On 12/06/15 15:13, Henning Schulzrinne wrote: >>>>> In almost all cases of interest, the calling party *wants* to >>>>> disclose accurate information to the called party, so the privacy >>>>> issues don't seem to arise. They would only arise if there was >>>>> forced disclosure; I don't think anybody is proposing that. >>>> >>>> Privacy issues could also arise if a middlebox could now see >>>> sensitive information that it previously could not see. I think that >>>> is independent of whether disclosure is desired by either of the >>>> endpoints. >>>> >>>> S. >>>> >>>> _______________________________________________ >>>> cnit mailing list >>>> cnit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cnit >>> >>> >>> _______________________________________________ >>> cnit mailing list >>> cnit@ietf.org >>> https://www.ietf.org/mailman/listinfo/cnit >> >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit > From nobody Sat Jun 13 15:47:43 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861711B3171 for ; Sat, 13 Jun 2015 15:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfYjNMQ3luYW for ; Sat, 13 Jun 2015 15:47:40 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B229A1B3170 for ; Sat, 13 Jun 2015 15:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434235659; x=1465771659; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xcMBDz4P4hSh9iJtBDA4kQ8Jw2vgpxmw1+JFzj8SACU=; b=lDUBmjzsnUY2/Pxms/EaEmbxGSNyDxkV/Itc8nD2P9GyQOfPZiMOLPw3 GHl2LNS8oFYIvCdWovFceCdd9VhKbdi1AApu0t202VhCIQafxbbr84c68 Mhs7vFcz+LCGGiliBdLltADFmI1vwp/3CRlbIIlTp3XCJvnhmwbO6zsIy k=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe01.verizonbusiness.com with ESMTP; 13 Jun 2015 22:47:37 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.13,610,1427760000"; d="scan'208";a="35394104" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 13 Jun 2015 22:47:37 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Sat, 13 Jun 2015 18:47:36 -0400 To: Henning Schulzrinne , Brian Rosen Date: Sat, 13 Jun 2015 18:47:35 -0400 Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tADGHMBA= Message-ID: <2B0F677F0B95454297753F58D4A07FA30279326E8D@FHDP1LUMXC7V31.us.one.verizon.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net>, <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: 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 Archived-At: Cc: "philippe.fouquart@orange.com" , Stephen Farrell , Richard Shockey , "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 22:47:42 -0000 Henning, I appreciate, and mostly agree with, your comments below. Please see addit= ional thoughts inline. tim -----Original Message----- From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, June 12, 2015 5:28 PM To: Dwight, Timothy M (Tim); Brian Rosen Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Richard S= hockey Subject: Re: [cnit] CNIT Charter bashing.. Today's CNAM display has three problems: (1) It is unclear to the recipient how the data got inserted and by whom. T= here is no realistic way for the callee to find out - good luck calling you= r phone company consumer support line and asking about CNAM database dips. [tmd] People do call their service provider's "support line" about issues w= ith calling name, and we do help them. Nobody will claim that that's easy = though. The information can be obtained in various ways from various sourc= es. The proliferation of non-authoritative calling name databases sometime= s leads to disputes over "whose data is correct", which can delay resolutio= n. (2) The caller has no idea what will be shown to any given called party - d= epending on the destination CNAM service, it could be the correct name, not= hing, just "Florida", or maybe the name of the person who had the same numb= er six months ago and hopefully didn't sell adult entertainment. [tmd] I agree that the caller generally cannot know what will be shown to a= ny given called party. I don't agree that this is always a function of the= _destination_ CNAM service, though. In "conventional" CNAM services (ref:= GR-1188) the terminating exchange does a TCAP query to obtain calling name= information from the originating network. The result is in that case dict= ated by the caller's service provider, since it is they (or a 3rd party to = whom they subcontract this service) who reply to the query.=20 (3) For some numbers, bad actors can insert any random information they cho= ose, again with problem #1. Even unsigned SIP display or Call-Info information, with some modicum of co= mmon behavior among carriers, will address all three problems, even if not = perfectly, then most of the time. I may have no idea what validation Verizo= n uses to assure that their customers are indeed John Smith, but at least I= know that I can tell who created the entry. A lawyer will know where to ad= dress the cease&desist letter if needed. [tmd] That would be a clever lawyer. As noted above, when incorrect callin= g name information is being displayed, it can be difficult to determine why= . I wish it were as simple as "if the caller is a Verizon customer, it mus= t be Verizon's fault". But it isn't. Consider customers A and B. A is a = Verizon customer. B is a CarrierB customer. CarrierB uses 3rdPartyCnamLik= e service to obtain calling name information for incoming calls. When A ca= lls B, the name displayed to B doesn't come from Verizon.=20 ________________________________________ From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] Sent: Friday, June 12, 2015 3:21 PM To: Brian Rosen Cc: Richard Shockey; philippe.fouquart@orange.com; Henning Schulzrinne; cni= t@ietf.org; Stephen Farrell Subject: RE: [cnit] CNIT Charter bashing.. I guess as long as the derivation of the name (who is asserting it to be a = valid representation of the caller, and from where did they get it) is clea= r to the receiving network, I guess this is OK. I still have my doubts whe= ther such a value will prove useful, given that its computation is not stan= dardized. But in some contexts, it might. Tim -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, June 12, 2015 12:51 PM To: Dwight, Timothy M (Tim) Cc: Richard Shockey; philippe.fouquart@orange.com; Henning Schulzrinne; cni= t@ietf.org; Stephen Farrell Subject: Re: [cnit] CNIT Charter bashing.. Yes, it would be assigned by the entity that signed the name. It's not true that it would always be the highest possible value. If the e= ntity that provided it did that, the receiving entity might not believe it,= and choose to use an alternative name source (or at least check another se= rvice to see what it thought). Modern systems that collect names subject u= ser data with verification sources that are getting very accurate, but thos= e services have scoring systems that don't result in black/white results. = Older systems blithely accept whatever the customer says, and those are not= accurate. Some services have something simpler, like the name has to matc= h a credit card name, but we know those are pretty spoofable these days. R= eal systems use external verification services that provide scores for this= kind of thing. I'm simply proposing that we allow an optional confidence, in the range of = 0-100, and that it be part of the data signed by the data provider. No one= has to send it, no one has to look at it. But it represents what is state= of the art these days on asserting names and I think it's valuable. Brian > On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) wrote: > > Who would assign the confidence value? If it's assigned by the entity th= at operates the calling name database, why would it ever be less than the h= ighest possible value? If it's set by some other entity, on what basis do = they determine the value they assign? It seems like we're going to stumble= over business issues. > > Tim > > > -----Original Message----- > From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Friday, June 12, 2015 11:28 AM > To: Richard Shockey > Cc: philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org;=20 > Stephen Farrell > Subject: Re: [cnit] CNIT Charter bashing.. > > One possible extra bit is that we need to know WHO signed. That could be= easy (identity in a cert for the signature), but it's a requirement. > > I still want an optional confidence value, because the source is often no= t authoritative. > > If we're thinking we're using the existing display name, and coming up wi= th a way to sign it, then, like stir, the termination side can decide what = it wants to do if it gets a display name but no signature. The sender has = the option to provide the name or not, and provide the signature or not. > > We COULD consider a new header that would contain the name encrypted for = a destination TN (To:). That would afford privacy to the name to middle bo= xes that we would not have today with display name. I would not be opposed= to that. This would work like the offline stir proposal, where the sender= obtains the public key of the recipient and encrypts the name for the reci= pient. > > Brian > >> On Jun 12, 2015, at 8:49 AM, Richard Shockey wrote: >> >> >> Henning is right. No one is forcing anything. Existing anonymous=20 >> calling protections still apply. >> >> >> Again my point is that is a great many cases Interconnected SIP=20 >> between NA carriers are covered by other security mechanisms. >> >> Right now your Facetime session is totally in the clear. My concern=20 >> is we end up going down the rat hole of trying to create perfect end=20 >> to end security nothing will get done. >> >> >> >> On 6/12/15, 10:17 AM, "Stephen Farrell" wrot= e: >> >>> >>> >>> On 12/06/15 15:13, Henning Schulzrinne wrote: >>>> In almost all cases of interest, the calling party *wants* to=20 >>>> disclose accurate information to the called party, so the privacy=20 >>>> issues don't seem to arise. They would only arise if there was=20 >>>> forced disclosure; I don't think anybody is proposing that. >>> >>> Privacy issues could also arise if a middlebox could now see=20 >>> sensitive information that it previously could not see. I think that=20 >>> is independent of whether disclosure is desired by either of the=20 >>> endpoints. >>> >>> S. >>> >>> _______________________________________________ >>> cnit mailing list >>> cnit@ietf.org >>> https://www.ietf.org/mailman/listinfo/cnit >> >> >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit > > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From nobody Sat Jun 13 16:13:34 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CA11B319F for ; Sat, 13 Jun 2015 16:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U8ELRiB6PfM for ; Sat, 13 Jun 2015 16:13:30 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CB41A92B3 for ; Sat, 13 Jun 2015 16:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434237210; x=1465773210; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uxAKrvnbOBJC/SGW3CoaNmmnfXXIS8gLcsFYqJuNKQY=; b=O00URPisP+LSc0uFZQmSWMYAX1Hv290TN2elqgx8TXyDJWA72OSnAPtY /5MfpMCq3KmREnf/0iEQ5yGTTUU0tL7CX4/6FN8ddC+0C8wmxK1X12Aw+ 5k/tblL6ZGHf5VSiPbqseQpKtbI0cW0vnsJlj1NEpu09jnlP4h1Xy1RDX U=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe03.verizon.com with ESMTP; 13 Jun 2015 23:13:28 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.13,610,1427760000"; d="scan'208";a="35395668" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 13 Jun 2015 23:13:28 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Sat, 13 Jun 2015 19:13:28 -0400 To: Henning Schulzrinne , "cnit@ietf.org" Date: Sat, 13 Jun 2015 19:09:33 -0400 Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAABA5AIAAH5PPgAGUY3A= Message-ID: <2B0F677F0B95454297753F58D4A07FA30279326E8E@FHDP1LUMXC7V31.us.one.verizon.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> , <2B0F677F0B95454297753F58D4A07FA30279326B59@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: 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 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 23:13:33 -0000 Henning, As you may know, there are controls over disclosure of calling name data th= at mirror those which govern disclosure of calling number. In the conventi= onal CNAM model these are attributes in the LIDB. These need either to be = explicitly changed (e.g., if consumers no longer need these protections) or= replicated into whatever alternative model this group develops. Since it'= s not up to the IETF to determine public policy, I guess we're best off try= ing to replicate the existing functionality. Intuitively I agree that an entity with a "public" or "semi-public" telepho= ne number would probably not object to their name being displayed to people= they call. But that is not necessarily the case. All I can say for sure = is that today consumers have control over this (you can mark your name "pub= lic" or "private" in the LIDB; and you can ask that name presentation be "= tied" to number presentation - i.e., if you can ask that presentation of yo= ur name be blocked if presentation of your number is blocked, either perman= ently or call-by-call). Similarly I can't say for sure whether anyone would object to their name be= ing visible to networks or network elements to which it is not visible toda= y. I think if we propose to increase its visibility the onus is on us to b= e sure. Tim -----Original Message----- From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, June 12, 2015 5:48 PM To: Dwight, Timothy M (Tim); cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. I suspect there could be cases where a caller objects to the disclosure to = intermediate entities; they clearly should have the option of not including= the name information, either on a call-by-call or global basis. I'm guessi= ng that this is a rare case; for the entities most reliant on caller name i= nformation, namely entities that cannot count on being in the address book = of the called party, they usually have semi-public telephone numbers, so th= at the mapping to the name is essentially public. As I noted, as long as ro= ughly the same information is in-band as out-of-band today, every single ca= rrier can already look up CNAM information if they are so inclined. Thus, I= 'm not quite following how this makes things worse. (The difference is that= today, I can look up CNAM information for any phone number, even if the en= tity never called me. In-band delivery would obviate the need for CNAM data= bases, so it would seem to make things better, not worse.) The latter point obviously only applies to countries with CNAM; as long as = the opt-in/opt-out nature is preserved, this seems more like a disclosure i= ssue ("your name is visible to your carrier and, if the carrier is too lazy= to implement SIP over TLS, any national intelligence agency that happens t= o be watching that fiber"). ________________________________________ From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] Sent: Friday, June 12, 2015 12:47 PM To: Richard Shockey; Stephen Farrell; Henning Schulzrinne; philippe.fouquar= t@orange.com; cnit@ietf.org Subject: RE: [cnit] CNIT Charter bashing.. Rich, I'm probably not following this right, so bear with me. In the current par= adigm the calling party's name isn't sent in the call request message, righ= t? But you're proposing that it should be (or optionally could be, whateve= r). Doesn't that open up the possibility Mr. Farrell suggested, that some = entity that's in the path of the call request message can "see" something h= e previously could not? Note that "existing anonymous calling protections" apply to the presentatio= n of information to the user, not necessarily to carriage of information ac= ross the network. The FROM header may be anonymized when the calling user = requests privacy, for example, but the P-Asserted-Identity header will not.= So if we were to use the display name in the P-A-ID to carry the calling = party name asserted by the originating network, that name would (unless we = encrypt it) be "visible" to any network element on the path of the INVITE. tim -----Original Message----- From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Friday, June 12, 2015 10:50 AM To: Stephen Farrell; Henning Schulzrinne; philippe.fouquart@orange.com; cni= t@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. Henning is right. No one is forcing anything. Existing anonymous calling pr= otections still apply. Again my point is that is a great many cases Interconnected SIP between NA = carriers are covered by other security mechanisms. Right now your Facetime session is totally in the clear. My concern is we e= nd up going down the rat hole of trying to create perfect end to end securi= ty nothing will get done. On 6/12/15, 10:17 AM, "Stephen Farrell" wrote: > > >On 12/06/15 15:13, Henning Schulzrinne wrote: >> In almost all cases of interest, the calling party *wants* to=20 >> disclose accurate information to the called party, so the privacy=20 >> issues don't seem to arise. They would only arise if there was forced=20 >> disclosure; I don't think anybody is proposing that. > >Privacy issues could also arise if a middlebox could now see sensitive=20 >information that it previously could not see. I think that is=20 >independent of whether disclosure is desired by either of the=20 >endpoints. > >S. > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From nobody Sun Jun 14 06:50:17 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971FB1A8753 for ; Sun, 14 Jun 2015 06:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir8T1F8cZfBV for ; Sun, 14 Jun 2015 06:50:14 -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 A49441A8758 for ; Sun, 14 Jun 2015 06:50:12 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" , "cnit@ietf.org" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAABA5AIAAH5PPgAGUY3CAAPphQA== Date: Sun, 14 Jun 2015 13:50:11 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> , <2B0F677F0B95454297753F58D4A07FA30279326B59@FHDP1LUMXC7V31.us.one.verizon.com> , <2B0F677F0B95454297753F58D4A07FA30279326E8E@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30279326E8E@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 Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 13:50:16 -0000 With in-band delivery, controlling delivery of information should, in theor= y, be easier, since we no longer rely on third-party services.=0A= =0A= My guess is that many PBX and SIP trunking systems rely on companies like O= penCNAM or the other service providers listed at http://www.voip-info.org/w= iki/view/CNAM . They currently can't provide call-by-call privacy, only a g= lobal "always on"/"always off" setting.=0A= =0A= Thus, I think we all agree that callers should have control, either permane= ntly or maybe call-by-call, on whether to disclose caller name information,= and callers should be aware that this information may be visible to carrie= rs in the call path. (In many cases, that's likely to be just the caller's = carrier and the destination carrier, but things obviously sometimes get mor= e complicated in rural call scenarios or if there's a separate LD carrier.)= =0A= =0A= Henning=0A= ________________________________________=0A= From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]=0A= Sent: Saturday, June 13, 2015 7:09 PM=0A= To: Henning Schulzrinne; cnit@ietf.org=0A= Subject: RE: [cnit] CNIT Charter bashing..=0A= =0A= Henning,=0A= =0A= As you may know, there are controls over disclosure of calling name data th= at mirror those which govern disclosure of calling number. In the conventi= onal CNAM model these are attributes in the LIDB. These need either to be = explicitly changed (e.g., if consumers no longer need these protections) or= replicated into whatever alternative model this group develops. Since it'= s not up to the IETF to determine public policy, I guess we're best off try= ing to replicate the existing functionality.=0A= =0A= Intuitively I agree that an entity with a "public" or "semi-public" telepho= ne number would probably not object to their name being displayed to people= they call. But that is not necessarily the case. All I can say for sure = is that today consumers have control over this (you can mark your name "pub= lic" or "private" in the LIDB; and you can ask that name presentation be "= tied" to number presentation - i.e., if you can ask that presentation of yo= ur name be blocked if presentation of your number is blocked, either perman= ently or call-by-call).=0A= =0A= Similarly I can't say for sure whether anyone would object to their name be= ing visible to networks or network elements to which it is not visible toda= y. I think if we propose to increase its visibility the onus is on us to b= e sure.=0A= =0A= Tim=0A= =0A= From nobody Sun Jun 14 06:55:34 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D8C1A8753 for ; Sun, 14 Jun 2015 06:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.712 X-Spam-Level: X-Spam-Status: No, score=-3.712 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PunBHQBeXeY0 for ; Sun, 14 Jun 2015 06:55:31 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id E829E1A874F for ; Sun, 14 Jun 2015 06:55:30 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tADGHMBAAITkHRA== Date: Sun, 14 Jun 2015 13:55:28 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net>, <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> , <2B0F677F0B95454297753F58D4A07FA30279326E8D@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30279326E8D@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 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 13:55:33 -0000 Just to clarify: For the lawyer remark, I meant the future in-band scenario= . I agree that under the current mode of operation, you'd need a private de= tective, not a lawyer. In the in-band case, carrier B would have no incenti= ve to use a third-party service, so a call from a number assigned to Verizo= n would always have caller name from Verizon (however they created it).=0A= =0A= The idea is that you don't need perfect validation if you can easily track = down who inserted the information. If the information is maliciously wrong,= it becomes feasible to use non-technical means to correct the information.= =0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]=0A= Sent: Saturday, June 13, 2015 6:47 PM=0A= To: Henning Schulzrinne; Brian Rosen=0A= Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Richard S= hockey=0A= Subject: RE: [cnit] CNIT Charter bashing..=0A= =0A= Henning,=0A= =0A= I appreciate, and mostly agree with, your comments below. Please see addit= ional thoughts inline.=0A= =0A= tim=0A= =0A= -----Original Message-----=0A= From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne= =0A= Sent: Friday, June 12, 2015 5:28 PM=0A= To: Dwight, Timothy M (Tim); Brian Rosen=0A= Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Richard S= hockey=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= Today's CNAM display has three problems:=0A= =0A= (1) It is unclear to the recipient how the data got inserted and by whom. T= here is no realistic way for the callee to find out - good luck calling you= r phone company consumer support line and asking about CNAM database dips.= =0A= =0A= [tmd] People do call their service provider's "support line" about issues w= ith calling name, and we do help them. Nobody will claim that that's easy = though. The information can be obtained in various ways from various sourc= es. The proliferation of non-authoritative calling name databases sometime= s leads to disputes over "whose data is correct", which can delay resolutio= n.=0A= =0A= =0A= (2) The caller has no idea what will be shown to any given called party - d= epending on the destination CNAM service, it could be the correct name, not= hing, just "Florida", or maybe the name of the person who had the same numb= er six months ago and hopefully didn't sell adult entertainment.=0A= =0A= [tmd] I agree that the caller generally cannot know what will be shown to a= ny given called party. I don't agree that this is always a function of the= _destination_ CNAM service, though. In "conventional" CNAM services (ref:= GR-1188) the terminating exchange does a TCAP query to obtain calling name= information from the originating network. The result is in that case dict= ated by the caller's service provider, since it is they (or a 3rd party to = whom they subcontract this service) who reply to the query.=0A= =0A= =0A= (3) For some numbers, bad actors can insert any random information they cho= ose, again with problem #1.=0A= =0A= Even unsigned SIP display or Call-Info information, with some modicum of co= mmon behavior among carriers, will address all three problems, even if not = perfectly, then most of the time. I may have no idea what validation Verizo= n uses to assure that their customers are indeed John Smith, but at least I= know that I can tell who created the entry. A lawyer will know where to ad= dress the cease&desist letter if needed.=0A= =0A= [tmd] That would be a clever lawyer. As noted above, when incorrect callin= g name information is being displayed, it can be difficult to determine why= . I wish it were as simple as "if the caller is a Verizon customer, it mus= t be Verizon's fault". But it isn't. Consider customers A and B. A is a = Verizon customer. B is a CarrierB customer. CarrierB uses 3rdPartyCnamLik= e service to obtain calling name information for incoming calls. When A ca= lls B, the name displayed to B doesn't come from Verizon.=0A= =0A= From nobody Sun Jun 14 07:01:48 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F326E1A004B for ; Sun, 14 Jun 2015 07:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFRHjxzRwFzO for ; Sun, 14 Jun 2015 07:01:46 -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 72B8D1A877C for ; Sun, 14 Jun 2015 07:01:46 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tAA73xIAARAClgQ== Date: Sun, 14 Jun 2015 14:01:44 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 14:01:48 -0000 The VoLTE/IMS experts listening probably know this better, but judging from= some quick Googling of sample VoLTE call flows, SIP display name informati= on is already part of the IMS/VoLTE standards, so model #1 (NNI) shouldn't = be that hard, and we can then build on that, as you hint at.=0A= =0A= I suspect we all agree that the barrier to entry should be minimal. We can = discuss, for example, whether a by-reference or by-value mechanism is bette= r, or we need both.=0A= =0A= ________________________________________=0A= From: Richard Shockey [richard@shockey.us]=0A= Sent: Friday, June 12, 2015 9:29 PM=0A= To: Henning Schulzrinne; Dwight, Timothy M (Tim); Brian Rosen=0A= Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Ben Campb= ell=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= Henning the biggest issue is that any form of advanced CNAM display is not= =0A= currently applicable to the the mobile access devices. Which are now=0A= finally over 50% of the NANP even if you consider BYOD in the enterprise.= =0A= Yea that is another use case.=0A= =0A= Hence the issue with Apple. This is ultimately a problem with that will=0A= have to be coordinated with US GSMA or GSMA generally.=0A= =0A= Or IMHO with the the 8th floor on 12th st. It really is a jawboning use.=0A= Tom needs to call Tim Cook or Larry Page and make the ask.=0A= =0A= I do reject Brians pretense here. Given the IETF context perfection is=0A= actually the enemy of deployment.=0A= =0A= I want a charter that is simple and clear. Header and object. Period. If= =0A= that is impossible then =8A..=0A= =0A= Its time the AD=B9s decide.=0A= =0A= From nobody Sun Jun 14 07:25:25 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E091A8547 for ; Sun, 14 Jun 2015 07:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYLjS44Rai32 for ; Sun, 14 Jun 2015 07:25:20 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 936271A854D for ; Sun, 14 Jun 2015 07:25:20 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Brian Rosen Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAAAqQY4AAUZSAgAJJIqQ= Date: Sun, 14 Jun 2015 14:25:18 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> , <31D54523-375B-42D6-A621-28A009E2DF20@brianrosen.net> In-Reply-To: <31D54523-375B-42D6-A621-28A009E2DF20@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 14:25:24 -0000 I just don't see this working. It gets worse in the way you describe since = there's no way for the the recipient to know what secret mix of tools the o= riginating carrier used, when they changed that secret mix and what the num= ber may mean. Also, unlike in the fraud case, where you have a good underly= ing ground truth (the bad guy stole your money or turns out to be a deadbea= t), with caller name information, the recipient has no good way to check wh= ether a score of 70 corresponds to anything. They'll only know if somebody = asserts "FBI" and it turns out that the caller doesn't have a badge.=0A= =0A= >From a consumer perspective, this is completely useless. What would I do wi= th a score of 70? Is that good or bad? Is it only good if the call is from = AT&T (which I won't know) but bad if it's from TMobile?=0A= =0A= I think we need more than assertion and "magic happens" here...=0A= =0A= More constructively, I think the model that provides broad indications of h= ow the information was derived is helpful:=0A= =0A= (1) self-asserted ("123 Bogus Street, Anytown" is acceptable)=0A= =0A= (2) validated (i.e., the company name exists and any other information, suc= h as street address, exists), but no guarantee that the caller is entitled = to that name=0A= =0A= (3) billing information (the name and location corresponds to a billing or = credit card record)=0A= =0A= (4) verified (using third party services such as KBA, above whatever thresh= old the originator considers good enough)=0A= =0A= This corresponds very roughly to the current web model - (1) is somebody's = gmail address or Google-hosted blog; (2) is a dedicated domain name with pl= ausible whois information; (3) is a standard TLS cert and (4) is an EV cert= .=0A= =0A= Henning=0A= =0A= =0A= ________________________________________=0A= From: Brian Rosen [br@brianrosen.net]=0A= Sent: Friday, June 12, 2015 7:20 PM=0A= To: Henning Schulzrinne=0A= Cc: cnit@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= Okay so, I=92ll try to give you meaningful answers to the questions you rai= se. I believe I=92ve done this before.=0A= > On Jun 12, 2015, at 3:39 PM, Henning Schulzrinne wrote:=0A= >=0A= > We have gone around that issue a few times, I think. Without trying to re= hash the arguments, I think the value is completely meaningless to the reci= pient. The value is currently used within a closed environment - company A = uses a validation service V and presumably gets a good sense of what "70" m= eans and whether that value is sufficiently high to do whatever they need t= o do (extend credit, open an account, show tax return information).=0A= =0A= Actually, many companies have multiple sources of information, and use more= than one of them some times. Since there is zero standardization, the com= pany has to know how to interpret the results, but since there are a relati= vely small number of sources, it works fine. When dealing with a simple sc= ore, you have some kind of a scaling factor that normalizes them. That ide= a will work just fine here. The receiving end will have scaling factors fo= r the sources it encounters. There may even be services that provide scali= ng factors. You accumulate and adjust your scaling factors based on the ob= servations you have on the data. Here, it might be customer complaints, or= UIs that have =93report errors=94 buttons, or periodic secondary validatio= n systems. My company could pretty easily calculate a pretty good set of s= caling factors given a large enough sample of historical call data with sco= res based on the databases we have. So can others. If a new scoring servi= ce shows up, it might have a pretty low scaling factor until you build up e= nough data to raise it.=0A= =0A= So the termination SP, or device, will apply a scale to the score based on = the identity of the source of the score and use that to determine what to d= o. Depending on the device, it could change the appearance of the name de= pending on the scaled score, or it could subject the name to alternative va= lidation, or use a third party name source.=0A= =0A= > When company B receives this information, it is completely meaningless to= that recipient, as the value will depend on what information the customer = A provided, whether A used V, W or X for validation and when this informati= on was validated. Does 70 mean that 70% of the customers with that type of = information are indeed who they claim to be? Or just that the person answer= ed 7 out of 10 questions correctly?=0A= The score can be defined as a confidence percentage. 70 means there is a 7= 0% chance the name is correct. The scoring service is free to use any meth= od it wants to come up with the score.=0A= >=0A= > Thus, this information is meant to be interpreted within a particular con= text, and taking it out of this context renders it meaningless.=0A= The context is very well defined - what is the name of the entity placing t= he call? The score is the confidence we have in the answer provided.=0A= =0A= >=0A= > Thus, unless these issues can be addressed, we would be conveying informa= tion that pretends to be accurate, but is just noise. Brian, you repeat the= same idea, but never address the issues that get raised again and again. T= his is not helpful.=0A= No, it=92s the exact opposite. When you send just a name without a score, = you are pretending it=92s 100% accurate, and that is clearly wrong. When y= ou send a score, you acknowledge that the data is not 100% accurate, and yo= u show what your confidence is in the information you are providing. Since= we have a lot of experience, we know how to get quality scoring. What we = can=92t do is mandate a good scoring methodology or source, so we have to h= ave some more complications like the scaling factor. But we do that now, b= ecause there is lots of competition for data, having more than one source i= s common and yet we know they don=92t all provide the same quality of data.= So we deal with that.=0A= =0A= >=0A= > We also now know from the IRS tax return debacle that knowledge-based aut= hentication varies in quality. I'm sure whoever got access to the tax retur= ns scored a 100 on whatever questions the web site asked=85=0A= Certainly. Any scoring system can be gamed. Nothing is perfect. But just= saying the guy=92s name is Clark Kent is no where near as useful as saying= that Name Scoring Service Inc says there is an 93% probability that the gu= y=92s name is Clark Kent. If someone says 100%, you should not believe the= m.=0A= =0A= These kinds of systems are common. We use them in lots of environments. W= e know how they work. We know what their limitations are. This isn=92t ro= cket science, but it is data science. Why are you so skeptical of proven s= ystems?=0A= =0A= Brian=0A= >=0A= > ________________________________________=0A= > From: Brian Rosen [br@brianrosen.net]=0A= > Sent: Friday, June 12, 2015 1:51 PM=0A= > To: Dwight, Timothy M (Tim)=0A= > Cc: Richard Shockey; philippe.fouquart@orange.com; Henning Schulzrinne; c= nit@ietf.org; Stephen Farrell=0A= > Subject: Re: [cnit] CNIT Charter bashing..=0A= >=0A= > Yes, it would be assigned by the entity that signed the name.=0A= >=0A= > It=92s not true that it would always be the highest possible value. If t= he entity that provided it did that, the receiving entity might not believe= it, and choose to use an alternative name source (or at least check anothe= r service to see what it thought). Modern systems that collect names subje= ct user data with verification sources that are getting very accurate, but = those services have scoring systems that don=92t result in black/white resu= lts. Older systems blithely accept whatever the customer says, and those a= re not accurate. Some services have something simpler, like the name has t= o match a credit card name, but we know those are pretty spoofable these da= ys. Real systems use external verification services that provide scores fo= r this kind of thing.=0A= >=0A= > I=92m simply proposing that we allow an optional confidence, in the range= of 0-100, and that it be part of the data signed by the data provider. No= one has to send it, no one has to look at it. But it represents what is s= tate of the art these days on asserting names and I think it=92s valuable.= =0A= >=0A= > Brian=0A= >> On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) wrote:=0A= >>=0A= >> Who would assign the confidence value? If it's assigned by the entity t= hat operates the calling name database, why would it ever be less than the = highest possible value? If it's set by some other entity, on what basis do= they determine the value they assign? It seems like we're going to stumbl= e over business issues.=0A= >>=0A= >> Tim=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen=0A= >> Sent: Friday, June 12, 2015 11:28 AM=0A= >> To: Richard Shockey=0A= >> Cc: philippe.fouquart@orange.com; Henning Schulzrinne; cnit@ietf.org; St= ephen Farrell=0A= >> Subject: Re: [cnit] CNIT Charter bashing..=0A= >>=0A= >> One possible extra bit is that we need to know WHO signed. That could b= e easy (identity in a cert for the signature), but it=92s a requirement.=0A= >>=0A= >> I still want an optional confidence value, because the source is often n= ot authoritative.=0A= >>=0A= >> If we=92re thinking we=92re using the existing display name, and coming = up with a way to sign it, then, like stir, the termination side can decide = what it wants to do if it gets a display name but no signature. The sender= has the option to provide the name or not, and provide the signature or no= t.=0A= >>=0A= >> We COULD consider a new header that would contain the name encrypted for= a destination TN (To:). That would afford privacy to the name to middle b= oxes that we would not have today with display name. I would not be oppose= d to that. This would work like the offline stir proposal, where the sende= r obtains the public key of the recipient and encrypts the name for the rec= ipient.=0A= >>=0A= >> Brian=0A= >>=0A= >>> On Jun 12, 2015, at 8:49 AM, Richard Shockey wrote= :=0A= >>>=0A= >>>=0A= >>> Henning is right. No one is forcing anything. Existing anonymous=0A= >>> calling protections still apply.=0A= >>>=0A= >>>=0A= >>> Again my point is that is a great many cases Interconnected SIP=0A= >>> between NA carriers are covered by other security mechanisms.=0A= >>>=0A= >>> Right now your Facetime session is totally in the clear. My concern is= =0A= >>> we end up going down the rat hole of trying to create perfect end to=0A= >>> end security nothing will get done.=0A= >>>=0A= >>>=0A= >>>=0A= >>> On 6/12/15, 10:17 AM, "Stephen Farrell" wro= te:=0A= >>>=0A= >>>>=0A= >>>>=0A= >>>> On 12/06/15 15:13, Henning Schulzrinne wrote:=0A= >>>>> In almost all cases of interest, the calling party *wants* to=0A= >>>>> disclose accurate information to the called party, so the privacy=0A= >>>>> issues don't seem to arise. They would only arise if there was=0A= >>>>> forced disclosure; I don't think anybody is proposing that.=0A= >>>>=0A= >>>> Privacy issues could also arise if a middlebox could now see=0A= >>>> sensitive information that it previously could not see. I think that= =0A= >>>> is independent of whether disclosure is desired by either of the=0A= >>>> endpoints.=0A= >>>>=0A= >>>> S.=0A= >>>>=0A= >>>> _______________________________________________=0A= >>>> cnit mailing list=0A= >>>> cnit@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/cnit=0A= >>>=0A= >>>=0A= >>> _______________________________________________=0A= >>> cnit mailing list=0A= >>> cnit@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/cnit=0A= >>=0A= >> _______________________________________________=0A= >> cnit mailing list=0A= >> cnit@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/cnit=0A= >=0A= >=0A= =0A= =0A= From nobody Sun Jun 14 07:41:36 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17D81A88FF for ; Sun, 14 Jun 2015 07:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgtaNwEnTNh3 for ; Sun, 14 Jun 2015 07:41:32 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 7A8A11A88A6 for ; Sun, 14 Jun 2015 07:41:32 -0700 (PDT) Received: (qmail 12108 invoked by uid 0); 14 Jun 2015 14:41:32 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy1.mail.unifiedlayer.com with SMTP; 14 Jun 2015 14:41:32 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id gEB21q00G1MNPNq01EB5cT; Sun, 14 Jun 2015 08:11:11 -0600 X-Authority-Analysis: v=2.1 cv=GeGEw2nL c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=ZsyXEVtvAAAA:8 a=2IZrZAIaAAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=VRPa-xI3RsgKIgFULC4A:9 a=Pv41Ndke8qXIb0sd:21 a=zVvh3vgdKI-Yrjk9:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=jjJRv2iaVrtnpI9xExP1TUHR2VdpMRsCzYAP2mFa3g8=; b=nm6JYgQDnkre3T+PVJ2b6NFl5HpyyP9VWpLDnjF1XP7fdDJG4tsXHHa4g+Limib1bpk9Uhk/7RFN0CE2ZfHwyBNQYtcu640bGQBcrEZgCPPn9idZSJ9r4suDmINCnpj6; Received: from [108.56.131.149] (port=53026 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z48mp-0003nz-70; Sun, 14 Jun 2015 08:21:23 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Sun, 14 Jun 2015 10:21:19 -0400 From: Richard Shockey To: "Dwight, Timothy M (Tim)" , Henning Schulzrinne , "cnit@ietf.org" Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <2B0F677F0B95454297753F58D4A07FA30279326B59@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326E8E@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30279326E8E@FHDP1LUMXC7V31.us.one.verizon.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 14:41:34 -0000 Tim I hope we can remember that the use cases here are not always driven by consumer to consumer. B2B is equally important though the rules get tricky for B2C. On 6/13/15, 7:09 PM, "Dwight, Timothy M (Tim)" wrote: >Henning, > >As you may know, there are controls over disclosure of calling name data >that mirror those which govern disclosure of calling number. In the >conventional CNAM model these are attributes in the LIDB. These need >either to be explicitly changed (e.g., if consumers no longer need these >protections) or replicated into whatever alternative model this group >develops. Since it's not up to the IETF to determine public policy, I >guess we're best off trying to replicate the existing functionality. Hense my insistence on first simply looking at what headers are used here in order to maintain some interoperability. There are enough folks around here in DC that can deal with the policy questions. I certainly understand the concern about privacy issues. Its actually one of the more interesting parts of the issue. Who=B9s privacy are we trying to protect. The privacy of the calling party or the privacy of the called party? Should the called party have some rights to know who is calling? Or are we doomed to voice mail hell for the rest of eternity or worse. =20 http://www.bloomberg.com/news/articles/2014-12-22/coca-cola-disconnects-voi ce-mail-at-headquarters IMHO this development is directly the result of the industry not focusing on the underlying problem in the current service definition. BTW I don=B9t agree with all of the conclusions here. In fact there is some anecdotal evidence that that point to point voice communications is experiencing a small resurgence since real time voice communications does not leave a =B3paper trail=B2 nor subject to fat thumb =B3send all=B2 buttons and voice communications are not generally recorded except by the NSA for course. > >Intuitively I agree that an entity with a "public" or "semi-public" >telephone number would probably not object to their name being displayed >to people they call. But that is not necessarily the case. All I can >say for sure is that today consumers have control over this (you can mark >your name "public" or "private" in the LIDB; and you can ask that name >presentation be "tied" to number presentation - i.e., if you can ask that >presentation of your name be blocked if presentation of your number is >blocked, either permanently or call-by-call). > >Similarly I can't say for sure whether anyone would object to their name >being visible to networks or network elements to which it is not visible >today. I think if we propose to increase its visibility the onus is on >us to be sure. > >Tim > > >-----Original Message----- >From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne >Sent: Friday, June 12, 2015 5:48 PM >To: Dwight, Timothy M (Tim); cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > >I suspect there could be cases where a caller objects to the disclosure >to intermediate entities; they clearly should have the option of not >including the name information, either on a call-by-call or global basis. >I'm guessing that this is a rare case; for the entities most reliant on >caller name information, namely entities that cannot count on being in >the address book of the called party, they usually have semi-public >telephone numbers, so that the mapping to the name is essentially public. >As I noted, as long as roughly the same information is in-band as >out-of-band today, every single carrier can already look up CNAM >information if they are so inclined. Thus, I'm not quite following how >this makes things worse. (The difference is that today, I can look up >CNAM information for any phone number, even if the entity never called >me. In-band delivery would obviate the need for CNAM databases, so it >would seem to make things better, not worse.) > >The latter point obviously only applies to countries with CNAM; as long >as the opt-in/opt-out nature is preserved, this seems more like a >disclosure issue ("your name is visible to your carrier and, if the >carrier is too lazy to implement SIP over TLS, any national intelligence >agency that happens to be watching that fiber"). > >________________________________________ >From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] >Sent: Friday, June 12, 2015 12:47 PM >To: Richard Shockey; Stephen Farrell; Henning Schulzrinne; >philippe.fouquart@orange.com; cnit@ietf.org >Subject: RE: [cnit] CNIT Charter bashing.. > >Rich, > >I'm probably not following this right, so bear with me. In the current >paradigm the calling party's name isn't sent in the call request message, >right? But you're proposing that it should be (or optionally could be, >whatever). Doesn't that open up the possibility Mr. Farrell suggested, >that some entity that's in the path of the call request message can "see" >something he previously could not? > >Note that "existing anonymous calling protections" apply to the >presentation of information to the user, not necessarily to carriage of >information across the network. The FROM header may be anonymized when >the calling user requests privacy, for example, but the >P-Asserted-Identity header will not. So if we were to use the display >name in the P-A-ID to carry the calling party name asserted by the >originating network, that name would (unless we encrypt it) be "visible" >to any network element on the path of the INVITE. > >tim > > >-----Original Message----- >From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Richard Shockey >Sent: Friday, June 12, 2015 10:50 AM >To: Stephen Farrell; Henning Schulzrinne; philippe.fouquart@orange.com; >cnit@ietf.org >Subject: Re: [cnit] CNIT Charter bashing.. > > >Henning is right. No one is forcing anything. Existing anonymous calling >protections still apply. > > >Again my point is that is a great many cases Interconnected SIP between >NA carriers are covered by other security mechanisms. > >Right now your Facetime session is totally in the clear. My concern is we >end up going down the rat hole of trying to create perfect end to end >security nothing will get done. > > > >On 6/12/15, 10:17 AM, "Stephen Farrell" wrote: > >> >> >>On 12/06/15 15:13, Henning Schulzrinne wrote: >>> In almost all cases of interest, the calling party *wants* to >>> disclose accurate information to the called party, so the privacy >>> issues don't seem to arise. They would only arise if there was forced >>> disclosure; I don't think anybody is proposing that. >> >>Privacy issues could also arise if a middlebox could now see sensitive >>information that it previously could not see. I think that is >>independent of whether disclosure is desired by either of the >>endpoints. >> >>S. >> >>_______________________________________________ >>cnit mailing list >>cnit@ietf.org >>https://www.ietf.org/mailman/listinfo/cnit > > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit > > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit From nobody Sun Jun 14 07:56:04 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701F21A896C for ; Sun, 14 Jun 2015 07:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvN_PiwDbiyp for ; Sun, 14 Jun 2015 07:56:02 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 12B741A8966 for ; Sun, 14 Jun 2015 07:56:02 -0700 (PDT) Received: (qmail 16089 invoked by uid 0); 14 Jun 2015 14:55:58 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy4.mail.unifiedlayer.com with SMTP; 14 Jun 2015 14:55:58 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id gLUu1q00w1MNPNq01LUxs0; Sun, 14 Jun 2015 14:29:06 -0600 X-Authority-Analysis: v=2.1 cv=K/SxQUmI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=V2tbnXzNJl_QKNLKy9EA:9 a=hGY4H5oG8KYgw0kz:21 a=mH9SIRAf-OHzb-j1:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=0ExX50eO19tLDRUCM0WvujYzahc0g9/DsLYC/VhSueI=; b=O/FNLIBVW0A7mD5rNucd6mTYmNB39Z+SBa2przI4fpVHqfjKr48J/RtysspIQd3FmA5KxOoAmQzQvAHJ3e7NFwhywteVOS10/KOwdrgVXuQ67FkjmBX5+xFkFRbrb/1e; Received: from [108.56.131.149] (port=53037 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z490k-0004yE-PH; Sun, 14 Jun 2015 08:35:47 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Sun, 14 Jun 2015 10:35:43 -0400 From: Richard Shockey To: Henning Schulzrinne Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 14:56:03 -0000 On 6/14/15, 10:01 AM, "Henning Schulzrinne" wrote: >The VoLTE/IMS experts listening probably know this better, but judging >from some quick Googling of sample VoLTE call flows, SIP display name >information is already part of the IMS/VoLTE standards, so model #1 (NNI) >shouldn't be that hard, and we can then build on that, as you hint at. Agreed. Its how the mobile CUA deals with the INVITE that contains the data it that is very unclear to me. That is ultimately a issue 3GPP GSMA or US GSMA should know something about. > >I suspect we all agree that the barrier to entry should be minimal. We >can discuss, for example, whether a by-reference or by-value mechanism is >better, or we need both. Agreed. =20 > >________________________________________ >From: Richard Shockey [richard@shockey.us] >Sent: Friday, June 12, 2015 9:29 PM >To: Henning Schulzrinne; Dwight, Timothy M (Tim); Brian Rosen >Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Ben >Campbell >Subject: Re: [cnit] CNIT Charter bashing.. > >Henning the biggest issue is that any form of advanced CNAM display is not >currently applicable to the the mobile access devices. Which are now >finally over 50% of the NANP even if you consider BYOD in the enterprise. >Yea that is another use case. > >Hence the issue with Apple. This is ultimately a problem with that will >have to be coordinated with US GSMA or GSMA generally. > >Or IMHO with the the 8th floor on 12th st. It really is a jawboning use. >Tom needs to call Tim Cook or Larry Page and make the ask. > >I do reject Brians pretense here. Given the IETF context perfection is >actually the enemy of deployment. > >I want a charter that is simple and clear. Header and object. Period. If >that is impossible then =C5=A0.. > >Its time the AD=C2=B9s decide. > > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit From nobody Sun Jun 14 10:58:40 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237E01B3076 for ; Sun, 14 Jun 2015 10:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoeh8S_iFdit for ; Sun, 14 Jun 2015 10:58:37 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AF11B3073 for ; Sun, 14 Jun 2015 10:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434304718; x=1465840718; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/lUlbqndxlZp/mwt7qPTsY3bMgsmCdpF44EwfTb7E98=; b=mAzFEGpdYriu9aT6QyPIQak7fIaWuOZawSdnC2iG1kT7RGnadze6aYGK 7bW51UL8TKAinQEXDFNioVAdrMrXdee4U7AARZvbRvcFhzA9lyn5KnW2t hM/FrZdDfbi9VoJF6YvE+9hGMEHrCbOtTb40osNpvAU2YM5biphRkeiCS 8=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 14 Jun 2015 17:58:25 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.13,614,1427760000"; d="scan'208";a="1019132201" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi02.verizon.com with ESMTP; 14 Jun 2015 17:58:25 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Sun, 14 Jun 2015 13:58:24 -0400 To: Henning Schulzrinne Date: Sun, 14 Jun 2015 13:58:20 -0400 Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tADGHMBAAITkHRAAICivQ Message-ID: <2B0F677F0B95454297753F58D4A07FA30279326EC8@FHDP1LUMXC7V31.us.one.verizon.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net>, <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> , <2B0F677F0B95454297753F58D4A07FA30279326E8D@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: 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 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 17:58:39 -0000 Henning, I'm not sure 'carrier B' would in the "in-band case" have no incentive to u= se a 3rd party service. It might be that the 3rd party service provides ad= ditional information and/or is considered more trustworthy than whoever pro= vided the in-band information. We can (and I hope will) change the incenti= ves. I think it would be a reasonable objective to carry whatever content = is deemed "necessary" to serve the public, in-band. If people want to oper= ate databases full of calling party's cat pictures, and Carrier B wants to = provide this to their customer (or allow their customer to obtain it themse= lves, e.g., provide them a link to it) that's all OK with me. I agree with you about the importance of being able to know unambiguously, = who inserted the information. Tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Sunday, June 14, 2015 8:55 AM To: Dwight, Timothy M (Tim) Cc: cnit@ietf.org Subject: RE: [cnit] CNIT Charter bashing.. Just to clarify: For the lawyer remark, I meant the future in-band scenario= . I agree that under the current mode of operation, you'd need a private de= tective, not a lawyer. In the in-band case, carrier B would have no incenti= ve to use a third-party service, so a call from a number assigned to Verizo= n would always have caller name from Verizon (however they created it). The idea is that you don't need perfect validation if you can easily track = down who inserted the information. If the information is maliciously wrong,= it becomes feasible to use non-technical means to correct the information.= =20 Henning ________________________________________ From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] Sent: Saturday, June 13, 2015 6:47 PM To: Henning Schulzrinne; Brian Rosen Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Richard S= hockey Subject: RE: [cnit] CNIT Charter bashing.. Henning, I appreciate, and mostly agree with, your comments below. Please see addit= ional thoughts inline. tim -----Original Message----- From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, June 12, 2015 5:28 PM To: Dwight, Timothy M (Tim); Brian Rosen Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Richard S= hockey Subject: Re: [cnit] CNIT Charter bashing.. Today's CNAM display has three problems: (1) It is unclear to the recipient how the data got inserted and by whom. T= here is no realistic way for the callee to find out - good luck calling you= r phone company consumer support line and asking about CNAM database dips. [tmd] People do call their service provider's "support line" about issues w= ith calling name, and we do help them. Nobody will claim that that's easy = though. The information can be obtained in various ways from various sourc= es. The proliferation of non-authoritative calling name databases sometime= s leads to disputes over "whose data is correct", which can delay resolutio= n. (2) The caller has no idea what will be shown to any given called party - d= epending on the destination CNAM service, it could be the correct name, not= hing, just "Florida", or maybe the name of the person who had the same numb= er six months ago and hopefully didn't sell adult entertainment. [tmd] I agree that the caller generally cannot know what will be shown to a= ny given called party. I don't agree that this is always a function of the= _destination_ CNAM service, though. In "conventional" CNAM services (ref:= GR-1188) the terminating exchange does a TCAP query to obtain calling name= information from the originating network. The result is in that case dict= ated by the caller's service provider, since it is they (or a 3rd party to = whom they subcontract this service) who reply to the query. (3) For some numbers, bad actors can insert any random information they cho= ose, again with problem #1. Even unsigned SIP display or Call-Info information, with some modicum of co= mmon behavior among carriers, will address all three problems, even if not = perfectly, then most of the time. I may have no idea what validation Verizo= n uses to assure that their customers are indeed John Smith, but at least I= know that I can tell who created the entry. A lawyer will know where to ad= dress the cease&desist letter if needed. [tmd] That would be a clever lawyer. As noted above, when incorrect callin= g name information is being displayed, it can be difficult to determine why= . I wish it were as simple as "if the caller is a Verizon customer, it mus= t be Verizon's fault". But it isn't. Consider customers A and B. A is a = Verizon customer. B is a CarrierB customer. CarrierB uses 3rdPartyCnamLik= e service to obtain calling name information for incoming calls. When A ca= lls B, the name displayed to B doesn't come from Verizon. From nobody Sun Jun 14 11:21:45 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0D91A87A6 for ; Sun, 14 Jun 2015 11:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnxfGmPeG3Mr for ; Sun, 14 Jun 2015 11:21:42 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82E81A8782 for ; Sun, 14 Jun 2015 11:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434306102; x=1465842102; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QpLOyc7PpH8V8k32i3E0d4KKEmYC4AEv8Shjpz0erAc=; b=NJLyCB+Cu6R5fgHKRU2LLAnjUaxeKD6+fEahHc17wIYuBYku3Yc5iLu/ lWSF7VOjg5G55IiOyyUT+f/r2rA9WCzxTyUZW/46DqDjj7zPC6mEkX43f kkgv0JMBewjPqqnprY0/kbBAT4OiZjW1vcRBoTF+6LDr1gTZ0h4XjN+JD U=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 14 Jun 2015 18:21:39 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.13,614,1427760000"; d="scan'208";a="35488412" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 14 Jun 2015 18:21:41 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Sun, 14 Jun 2015 14:21:39 -0400 To: Henning Schulzrinne , Richard Shockey Date: Sun, 14 Jun 2015 14:21:38 -0400 Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tAA73xIAARAClgQAI3ukQ Message-ID: <2B0F677F0B95454297753F58D4A07FA30279326EC9@FHDP1LUMXC7V31.us.one.verizon.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 18:21:43 -0000 This sounds right. 3GPP IMS standards support both user-provided identity = information (the FROM header) and network-provided identity information (th= e P-Asserted-Identity header). Both can optionally include a display-name.= =20 The Originating Identity Presentation (OIP) and Originating Identity Restri= ction (OIR) services generally govern presentation to the called user of th= e network-provided identity information. The network may or may not also r= estrict (in the case of OIR) presentation of the user-provided identity inf= ormation. tim -----Original Message----- From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, June 14, 2015 9:02 AM To: Richard Shockey Cc: cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. The VoLTE/IMS experts listening probably know this better, but judging from= some quick Googling of sample VoLTE call flows, SIP display name informati= on is already part of the IMS/VoLTE standards, so model #1 (NNI) shouldn't = be that hard, and we can then build on that, as you hint at. I suspect we all agree that the barrier to entry should be minimal. We can = discuss, for example, whether a by-reference or by-value mechanism is bette= r, or we need both. ________________________________________ From: Richard Shockey [richard@shockey.us] Sent: Friday, June 12, 2015 9:29 PM To: Henning Schulzrinne; Dwight, Timothy M (Tim); Brian Rosen Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Ben Campb= ell Subject: Re: [cnit] CNIT Charter bashing.. Henning the biggest issue is that any form of advanced CNAM display is not = currently applicable to the the mobile access devices. Which are now finall= y over 50% of the NANP even if you consider BYOD in the enterprise. Yea that is another use case. Hence the issue with Apple. This is ultimately a problem with that will hav= e to be coordinated with US GSMA or GSMA generally. Or IMHO with the the 8th floor on 12th st. It really is a jawboning use. Tom needs to call Tim Cook or Larry Page and make the ask. I do reject Brians pretense here. Given the IETF context perfection is actu= ally the enemy of deployment. I want a charter that is simple and clear. Header and object. Period. If = that is impossible then =D0.. Its time the AD=B9s decide. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From nobody Sun Jun 14 11:42:19 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDB01A924A for ; Sun, 14 Jun 2015 11:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.887 X-Spam-Level: X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57dXUTZ8BcF7 for ; Sun, 14 Jun 2015 11:42:15 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B791A9245 for ; Sun, 14 Jun 2015 11:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=Uw03NmPBGjtMjpEY8HHSXClyeIbQU6yfXhWumcHg6aQ=; b=oLy85w/UTVjdgQpkYEHKfT4+1VrK7Q4V1wxUDh6D2aDUmCZehNRFxheWdHovTJ/JefPpwPk7E8brQ3jy8CJKPHAb2gdT2h4+a9pHaJ/Od3bWrc7fB0s46/JQOAHpJJtBfuIiylA76jCQrxfBAF/fOO8aMH5Xh/F80uIV0z00FuQ=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:65499 helo=[192.168.15.129]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Z4Cr7-0003Ka-5P for cnit@ietf.org; Sun, 14 Jun 2015 11:42:11 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_5C5B98E1-CDE7-4521-907D-61FE6D578E0B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5b6 From: Eric Burger In-Reply-To: Date: Sun, 14 Jun 2015 14:42:03 -0400 Message-Id: <1B18AE2F-C2C7-4B0B-A3FA-08F7BD90BD38@standardstrack.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <31D54523-375B-42D6-A621-28A009E2DF20@brianrosen.net> To: "cnit@ietf.org" X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-0.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [cnit] Who says I am me? I say it is me. I have no reason to trust you. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 18:42:18 -0000 --Apple-Mail=_5C5B98E1-CDE7-4521-907D-61FE6D578E0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 [changing the subject to be meaningful, kind of like a CNAM=85] I fully agree with Henning here for two reasons. Reason #1: the point of CNIT, STIR, MODERN, et al. is we are not dooming = ourselves to simply do IP versions of SS7. We already have that. My = expectation is for 99% of the use of CNIT, the calling name will be = inserted by the end user equipment (enterprise PBX or SIP phones) or the = carrier service provider (mobile, wireline replacement, broadband cable = telephony, etc.). What do we do with the 1% of calls that will come from non-service = provider endpoints? E.g., what if you had an open source Foo Fone? The = easy answer would be to say you are in a self-signed certificate bind. = If you want your name to pop up correctly, pay for a service that will = vouch for you. However, the IETF does not mandate business models. So, = one could envision some sort of PGP-like web of trust. However, that is = on the signing of the name, NOT on the number-to-name translation. Let = us be realistic: if I cannot trust the veracity of the name, I cannot = trust the veracity of the calling number, so all bets are off anyway. I thus see zero need for or value from some third-party number-to-name = translation service. This simply replicates all of the evils of the = current system when the players are NOT trying to be evil, but only = stupid. As an example, see Tim=92s emails on how CNAM does not work = today at: https://mailarchive.ietf.org/arch/msg/cnit/D7JeNaGHOjHJAaFi2jeT2Y_C1oA Now imagine the third-party number-to-name translation service DOES want = to be evil. Yuck! Nothing in what I have seen in CNIT would *prevent* third-party number = validation services or third-party number-to-name services from offering = such services. They work today: at my endpoint, *I* decide to do another = dip with these services. However, I see nothing in CNIT that would be = sensible for such a service to be in the *signaling* path. Reason #2: if the user or the user=92s service provider is in control of = inserting the signed calling name, then all of the user privacy = arguments evaporate. Who cares that a real calling name, THAT THE USER = WANTS DISPLAYED, gets sent in the signaling path? First of all, it is up = to the USER to send the information. Second, yes, this is different than = today=92s North American SS7 configuration. SURPRISE! We are talking = SIP, not SS7. We can do whatever we want. Given we have thirty years of = knowing sending only the number and later asking for the name is = hopelessly broken, why would we want to replicate that? Remember the = mantra: =93User Control is Good." It is unquestionably true that we are making it easier for amateurs to = find out the calling name by sniffing the signaling. This says they have = access to unencrypted signaling (probably already a problem). Moreover, = it is saying that they have access to the signaling and yet they DO NOT = have any access to a number-to-name translation data base. I would offer = the latter is a 0.0000000001% probability. If they have the = sophistication to crack sips (OK, not too hard, but not trivial), they = have access to any of the public number-to-name data bases out there. If we do want to protect from, for example, nation-states, we could = encrypt the name itself with the public key of the called party. If = someone is that paranoid, they will not mind the setup penalty in the = signaling. I doubt anyone would use it, but if that is what it takes to = get chartered, I=92ve got students who can write an I-D that nobody will = use but will get a publication ;-) > On Jun 14, 2015, at 10:25 AM, Henning Schulzrinne = wrote: >=20 > I just don't see this working. It gets worse in the way you describe = since there's no way for the the recipient to know what secret mix of = tools the originating carrier used, when they changed that secret mix = and what the number may mean. Also, unlike in the fraud case, where you = have a good underlying ground truth (the bad guy stole your money or = turns out to be a deadbeat), with caller name information, the recipient = has no good way to check whether a score of 70 corresponds to anything. = They'll only know if somebody asserts "FBI" and it turns out that the = caller doesn't have a badge. >=20 >> =46rom a consumer perspective, this is completely useless. What would = I do with a score of 70? Is that good or bad? Is it only good if the = call is from AT&T (which I won't know) but bad if it's from TMobile? >=20 > I think we need more than assertion and "magic happens" here... >=20 > More constructively, I think the model that provides broad indications = of how the information was derived is helpful: >=20 > (1) self-asserted ("123 Bogus Street, Anytown" is acceptable) >=20 > (2) validated (i.e., the company name exists and any other = information, such as street address, exists), but no guarantee that the = caller is entitled to that name >=20 > (3) billing information (the name and location corresponds to a = billing or credit card record) >=20 > (4) verified (using third party services such as KBA, above whatever = threshold the originator considers good enough) >=20 > This corresponds very roughly to the current web model - (1) is = somebody's gmail address or Google-hosted blog; (2) is a dedicated = domain name with plausible whois information; (3) is a standard TLS cert = and (4) is an EV cert. >=20 > Henning >=20 >=20 > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Friday, June 12, 2015 7:20 PM > To: Henning Schulzrinne > Cc: cnit@ietf.org > Subject: Re: [cnit] CNIT Charter bashing.. >=20 > Okay so, I=92ll try to give you meaningful answers to the questions = you raise. I believe I=92ve done this before. >> On Jun 12, 2015, at 3:39 PM, Henning Schulzrinne = wrote: >>=20 >> We have gone around that issue a few times, I think. Without trying = to rehash the arguments, I think the value is completely meaningless to = the recipient. The value is currently used within a closed environment - = company A uses a validation service V and presumably gets a good sense = of what "70" means and whether that value is sufficiently high to do = whatever they need to do (extend credit, open an account, show tax = return information). >=20 > Actually, many companies have multiple sources of information, and use = more than one of them some times. Since there is zero standardization, = the company has to know how to interpret the results, but since there = are a relatively small number of sources, it works fine. When dealing = with a simple score, you have some kind of a scaling factor that = normalizes them. That idea will work just fine here. The receiving end = will have scaling factors for the sources it encounters. There may even = be services that provide scaling factors. You accumulate and adjust = your scaling factors based on the observations you have on the data. = Here, it might be customer complaints, or UIs that have =93report = errors=94 buttons, or periodic secondary validation systems. My company = could pretty easily calculate a pretty good set of scaling factors given = a large enough sample of historical call data with scores based on the = databases we have. So can others. If a new scoring service shows up, = it might have a pretty low scaling factor until you build up enough data = to raise it. >=20 > So the termination SP, or device, will apply a scale to the score = based on the identity of the source of the score and use that to = determine what to do. Depending on the device, it could change the = appearance of the name depending on the scaled score, or it could = subject the name to alternative validation, or use a third party name = source. >=20 >> When company B receives this information, it is completely = meaningless to that recipient, as the value will depend on what = information the customer A provided, whether A used V, W or X for = validation and when this information was validated. Does 70 mean that = 70% of the customers with that type of information are indeed who they = claim to be? Or just that the person answered 7 out of 10 questions = correctly? > The score can be defined as a confidence percentage. 70 means there = is a 70% chance the name is correct. The scoring service is free to use = any method it wants to come up with the score. >>=20 >> Thus, this information is meant to be interpreted within a particular = context, and taking it out of this context renders it meaningless. > The context is very well defined - what is the name of the entity = placing the call? The score is the confidence we have in the answer = provided. >=20 >>=20 >> Thus, unless these issues can be addressed, we would be conveying = information that pretends to be accurate, but is just noise. Brian, you = repeat the same idea, but never address the issues that get raised again = and again. This is not helpful. > No, it=92s the exact opposite. When you send just a name without a = score, you are pretending it=92s 100% accurate, and that is clearly = wrong. When you send a score, you acknowledge that the data is not 100% = accurate, and you show what your confidence is in the information you = are providing. Since we have a lot of experience, we know how to get = quality scoring. What we can=92t do is mandate a good scoring = methodology or source, so we have to have some more complications like = the scaling factor. But we do that now, because there is lots of = competition for data, having more than one source is common and yet we = know they don=92t all provide the same quality of data. So we deal with = that. >=20 >>=20 >> We also now know from the IRS tax return debacle that knowledge-based = authentication varies in quality. I'm sure whoever got access to the tax = returns scored a 100 on whatever questions the web site asked=85 > Certainly. Any scoring system can be gamed. Nothing is perfect. But = just saying the guy=92s name is Clark Kent is no where near as useful as = saying that Name Scoring Service Inc says there is an 93% probability = that the guy=92s name is Clark Kent. If someone says 100%, you should = not believe them. >=20 > These kinds of systems are common. We use them in lots of = environments. We know how they work. We know what their limitations = are. This isn=92t rocket science, but it is data science. Why are you = so skeptical of proven systems? >=20 > Brian >>=20 >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Friday, June 12, 2015 1:51 PM >> To: Dwight, Timothy M (Tim) >> Cc: Richard Shockey; philippe.fouquart@orange.com; Henning = Schulzrinne; cnit@ietf.org; Stephen Farrell >> Subject: Re: [cnit] CNIT Charter bashing.. >>=20 >> Yes, it would be assigned by the entity that signed the name. >>=20 >> It=92s not true that it would always be the highest possible value. = If the entity that provided it did that, the receiving entity might not = believe it, and choose to use an alternative name source (or at least = check another service to see what it thought). Modern systems that = collect names subject user data with verification sources that are = getting very accurate, but those services have scoring systems that = don=92t result in black/white results. Older systems blithely accept = whatever the customer says, and those are not accurate. Some services = have something simpler, like the name has to match a credit card name, = but we know those are pretty spoofable these days. Real systems use = external verification services that provide scores for this kind of = thing. >>=20 >> I=92m simply proposing that we allow an optional confidence, in the = range of 0-100, and that it be part of the data signed by the data = provider. No one has to send it, no one has to look at it. But it = represents what is state of the art these days on asserting names and I = think it=92s valuable. >>=20 >> Brian >>> On Jun 12, 2015, at 9:56 AM, Dwight, Timothy M (Tim) = wrote: >>>=20 >>> Who would assign the confidence value? If it's assigned by the = entity that operates the calling name database, why would it ever be = less than the highest possible value? If it's set by some other entity, = on what basis do they determine the value they assign? It seems like = we're going to stumble over business issues. >>>=20 >>> Tim >>>=20 >>>=20 >>> -----Original Message----- >>> From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen >>> Sent: Friday, June 12, 2015 11:28 AM >>> To: Richard Shockey >>> Cc: philippe.fouquart@orange.com; Henning Schulzrinne; = cnit@ietf.org; Stephen Farrell >>> Subject: Re: [cnit] CNIT Charter bashing.. >>>=20 >>> One possible extra bit is that we need to know WHO signed. That = could be easy (identity in a cert for the signature), but it=92s a = requirement. >>>=20 >>> I still want an optional confidence value, because the source is = often not authoritative. >>>=20 >>> If we=92re thinking we=92re using the existing display name, and = coming up with a way to sign it, then, like stir, the termination side = can decide what it wants to do if it gets a display name but no = signature. The sender has the option to provide the name or not, and = provide the signature or not. >>>=20 >>> We COULD consider a new header that would contain the name encrypted = for a destination TN (To:). That would afford privacy to the name to = middle boxes that we would not have today with display name. I would = not be opposed to that. This would work like the offline stir proposal, = where the sender obtains the public key of the recipient and encrypts = the name for the recipient. >>>=20 >>> Brian >>>=20 >>>> On Jun 12, 2015, at 8:49 AM, Richard Shockey = wrote: >>>>=20 >>>>=20 >>>> Henning is right. No one is forcing anything. Existing anonymous >>>> calling protections still apply. >>>>=20 >>>>=20 >>>> Again my point is that is a great many cases Interconnected SIP >>>> between NA carriers are covered by other security mechanisms. >>>>=20 >>>> Right now your Facetime session is totally in the clear. My concern = is >>>> we end up going down the rat hole of trying to create perfect end = to >>>> end security nothing will get done. >>>>=20 >>>>=20 >>>>=20 >>>> On 6/12/15, 10:17 AM, "Stephen Farrell" = wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> On 12/06/15 15:13, Henning Schulzrinne wrote: >>>>>> In almost all cases of interest, the calling party *wants* to >>>>>> disclose accurate information to the called party, so the privacy >>>>>> issues don't seem to arise. They would only arise if there was >>>>>> forced disclosure; I don't think anybody is proposing that. >>>>>=20 >>>>> Privacy issues could also arise if a middlebox could now see >>>>> sensitive information that it previously could not see. I think = that >>>>> is independent of whether disclosure is desired by either of the >>>>> endpoints. >>>>>=20 >>>>> S. >>>>>=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 >>=20 >=20 >=20 >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit --Apple-Mail=_5C5B98E1-CDE7-4521-907D-61FE6D578E0B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVfcr8AAoJEDY/T2tCIPW3PiUP/Rn5RPN8PRUl5jdXIB0sbPZF oT8FgC5M8mVIta8uGw3Is11yAzbbr2kGXJKAQRGsycW2otIDwnBaL72nNVjqdfSw QRwRZ5eWOWvBI0+AlA11MJhksYZrkqtmNBWhHh1xr1mA+QSBIRNsHCFil5J5bGDN gxIj5sPrBTSSC3pPUsbaIKouwIER+GRV8gYt5WCc04m7R6D61byx46AMGAe0OnPO Vz7f5ogE3qPhXZzYaDirkA+cIZJxVALeiv1z+eMfspT20PII0JiURE1G7Pg0et2n qmbGtRL1XkdKDL/cGHtGTe9gvNI/Rukjtgr7faoJQEwsDRY9ukgHF5S3dCL0hbQz XTRxBUcSuTMbBWsOeYdOPG05t9j1TMevLV8nCLO+YSUN1zL8pZ0V8qV7iAMeLSbL cs9j5BN9/LfX0NnoU3L7sqJ5jY2693PlFUsAqSinmmZnY0XLe6w3DZlsvL6N+SZF GnIlEbMGGh0UVvSwRMHVwnCWKPnmEPEyr4qPaA9IAvWxUjnPUgvuzxR6SEFHRglT GgxIyNS+pg2+Ncgom/nnasPzLHSBogQQ7/oY5gcRVFo2bR6Ti5pKaKLhKGdg8XsD 3/J42cio3TdkSb3dhonPLJMQoVJczZEm3rwwPyjF4f1LmtNBikw0aXTPdpqJMHbR 3kgqPt70iHSVX7xMgjBD =dTle -----END PGP SIGNATURE----- --Apple-Mail=_5C5B98E1-CDE7-4521-907D-61FE6D578E0B-- From nobody Mon Jun 15 10:26:53 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010161A9102 for ; Mon, 15 Jun 2015 10:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqNy5slNcQEf for ; Mon, 15 Jun 2015 10:26:48 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B541A90FD for ; Mon, 15 Jun 2015 10:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434389208; x=1465925208; h=from:to:cc:date:subject:message-id:references: content-transfer-encoding:mime-version; bh=je/DNL3aw1GCoaI+ATFs77qclrp5SIWMqi9eygudpoI=; b=HhodLKj/hhQ54F2gpVS2KQbGoa+5XSJvb4wdZrjgzwvM30dzy4dQiAC6 drdMq3Oe79+tQIFESzzfEHVK0om7Gjqo/6F2/lqepm19KE7KAzehx3mS4 Q9/9b1or5oqdQpIdMhNFfhf/2Uy2L8KqIa9hXt0Yol4kOiPX5EDNo/tV7 o=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe03.verizonbusiness.com with ESMTP; 15 Jun 2015 17:26:46 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.13,620,1427760000"; d="scan'208";a="35762128" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 15 Jun 2015 17:26:46 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Mon, 15 Jun 2015 13:26:44 -0400 To: Henning Schulzrinne , Richard Shockey Date: Mon, 15 Jun 2015 13:26:43 -0400 Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tAA73xIAARAClgQAI3ukQAC96jcA= Message-ID: <2B0F677F0B95454297753F58D4A07FA3027932729C@FHDP1LUMXC7V31.us.one.verizon.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> , Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:26:51 -0000 A couple of clarifications suggested to me offline. First a quote from TS = 24.607, which defines the Originating Identity Presentation (OIP) and Origi= nating Identity Restriction (OIR) services: "The OIP service provides the terminating user with the possibility of r= eceiving trusted (i.e. network provided) identity information in order to i= dentify the originating user" Observations: a) it generally addresses network -provided identity (which normally transl= ates to the content of a P-Asserted-Identity header; though it allows as a = network option to remove P-A-ID and convey calling identity information in = the From header). b) It does not specify how the terminating network obtains the identity inf= ormation it "asserts" to the UE. The most obvious place would be from the = P-Asserted-Identity header it received in the request. But I don't see any= prohibition against other things, e.g., of the terminating network modifyi= ng the information it received in P-A-ID. One thought relevant to this dis= cussion is that the terminating network might do a CNAM query using the cal= ling number from a P-A-ID header extracted from the request as key, and put= the result in the display-name field of a P-Asserted-Identity header it se= nds to the UE. As far as I can tell the 3GPP spec does not prohibit such t= hings. c) it talks about providing the terminating user with the _possibility_ of = receiving calling user identity information. Which I believe means that it= governs network behavior but not the behavior of the terminating device. = The network may for example communicate a calling name in a P-A-ID header, = but the device might display instead the name it has in its contact list fo= r that number. Or the device might obtain a name from another source (e.g.= , query some name service), or display no name at all. Point being, the 3G= PP spec does not mandate what the human actually sees. tim -----Original Message----- From: Dwight, Timothy M (Tim)=20 Sent: Sunday, June 14, 2015 1:22 PM To: 'Henning Schulzrinne'; Richard Shockey Cc: cnit@ietf.org Subject: RE: [cnit] CNIT Charter bashing.. This sounds right. 3GPP IMS standards support both user-provided identity = information (the FROM header) and network-provided identity information (th= e P-Asserted-Identity header). Both can optionally include a display-name.= =20 The Originating Identity Presentation (OIP) and Originating Identity Restri= ction (OIR) services generally govern presentation to the called user of th= e network-provided identity information. The network may or may not also r= estrict (in the case of OIR) presentation of the user-provided identity inf= ormation. tim -----Original Message----- From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, June 14, 2015 9:02 AM To: Richard Shockey Cc: cnit@ietf.org Subject: Re: [cnit] CNIT Charter bashing.. The VoLTE/IMS experts listening probably know this better, but judging from= some quick Googling of sample VoLTE call flows, SIP display name informati= on is already part of the IMS/VoLTE standards, so model #1 (NNI) shouldn't = be that hard, and we can then build on that, as you hint at. I suspect we all agree that the barrier to entry should be minimal. We can = discuss, for example, whether a by-reference or by-value mechanism is bette= r, or we need both. ________________________________________ From: Richard Shockey [richard@shockey.us] Sent: Friday, June 12, 2015 9:29 PM To: Henning Schulzrinne; Dwight, Timothy M (Tim); Brian Rosen Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Ben Campb= ell Subject: Re: [cnit] CNIT Charter bashing.. Henning the biggest issue is that any form of advanced CNAM display is not = currently applicable to the the mobile access devices. Which are now finall= y over 50% of the NANP even if you consider BYOD in the enterprise. Yea that is another use case. Hence the issue with Apple. This is ultimately a problem with that will hav= e to be coordinated with US GSMA or GSMA generally. Or IMHO with the the 8th floor on 12th st. It really is a jawboning use. Tom needs to call Tim Cook or Larry Page and make the ask. I do reject Brians pretense here. Given the IETF context perfection is actu= ally the enemy of deployment. I want a charter that is simple and clear. Header and object. Period. If = that is impossible then =D0.. Its time the AD=B9s decide. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From nobody Mon Jun 15 14:39:10 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4251A8746 for ; Mon, 15 Jun 2015 14:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.904 X-Spam-Level: * X-Spam-Status: No, score=1.904 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_50=0.8, GB_PHARMACY=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8cDKSDZzAZB for ; Mon, 15 Jun 2015 14:39:06 -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 A055D1A8748 for ; Mon, 15 Jun 2015 14:39:05 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Eric Burger , "cnit@ietf.org" Thread-Topic: [cnit] Who says I am me? I say it is me. I have no reason to trust you. Thread-Index: AQHQptHgjGJJjViUs0yXviD2b11ltJ2uE5Ls Date: Mon, 15 Jun 2015 21:39:03 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <31D54523-375B-42D6-A621-28A009E2DF20@brianrosen.net> , <1B18AE2F-C2C7-4B0B-A3FA-08F7BD90BD38@standardstrack.com> In-Reply-To: <1B18AE2F-C2C7-4B0B-A3FA-08F7BD90BD38@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [cnit] Who says I am me? I say it is me. I have no reason to trust you. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 21:39:09 -0000 I've said this before, but I think in many cases, the name is less importan= t than some verifiable property. For example, apparently some durable medic= al equipment fraudsters use the display name MEDCARE. From a quick trademar= k search, there actually is a legitimate business with that name (Medcare D= iscount Pharmacy), but validating the name does not always protect against = user confusion. A flag that shows that this is a legitimate, licensed pharm= acy would be more useful and that type of validation can be provided by any= number of third-party entities. The number of such categories is very smal= l since the number of businesses that need to be state/federally-licensed a= nd that care about validation (your nail salon or florist may need a licens= e but is unlikely to care about tagging their phone calls) isn't that large= .=0A= =0A= Thus, validating names is useful, but 100% accuracy validation may be very = difficult to achieve (given the need for brevity and practical limitations = of sources of information in the age of IRS KBA bypass.) For example, I hav= e a credit card that uses a non-state-registered name (xyz consulting) and = a billing address validation might accept this as legitimate.=0A= =0A= As a side note, I recently used Dun&Bradstreet to access and modify my corp= orate (DUNS) record for a small entity I run. For their KBA, all I needed t= o know was the registered address, landline phone number and the last two d= igits of the SSN, plus some "did you ever use some-ridiculous-first-name" q= uestion. Not very confidence-inducing. Given that this small business has n= o credit history, this is not surprising - there just isn't much to work wi= th that isn't listed on the certificate of incorporation.=0A= =0A= Practically speaking, most names aren't worth faking. There seems little be= nefit to pretending to be Joe's Pizza or Adam Smith if you're not, except f= or pranks ("Did you just order 100 anchovy pizzas?"). Thus, protecting high= -value names is likely more productive, such as those of government agencie= s, utilities/carriers or financial institutions. =0A= =0A= ________________________________________=0A= From: cnit [cnit-bounces@ietf.org] on behalf of Eric Burger [eburger@standa= rdstrack.com]=0A= Sent: Sunday, June 14, 2015 2:42 PM=0A= To: cnit@ietf.org=0A= Subject: [cnit] Who says I am me? I say it is me. I have no reason to trust= you.=0A= =0A= [changing the subject to be meaningful, kind of like a CNAM=85]=0A= =0A= I fully agree with Henning here for two reasons.=0A= =0A= Reason #1: the point of CNIT, STIR, MODERN, et al. is we are not dooming ou= rselves to simply do IP versions of SS7. We already have that. My expectati= on is for 99% of the use of CNIT, the calling name will be inserted by the = end user equipment (enterprise PBX or SIP phones) or the carrier service pr= ovider (mobile, wireline replacement, broadband cable telephony, etc.).=0A= =0A= What do we do with the 1% of calls that will come from non-service provider= endpoints? E.g., what if you had an open source Foo Fone? The easy answer = would be to say you are in a self-signed certificate bind. If you want your= name to pop up correctly, pay for a service that will vouch for you. Howev= er, the IETF does not mandate business models. So, one could envision some = sort of PGP-like web of trust. However, that is on the signing of the name,= NOT on the number-to-name translation. Let us be realistic: if I cannot tr= ust the veracity of the name, I cannot trust the veracity of the calling nu= mber, so all bets are off anyway.=0A= =0A= I thus see zero need for or value from some third-party number-to-name tran= slation service. This simply replicates all of the evils of the current sys= tem when the players are NOT trying to be evil, but only stupid. As an exam= ple, see Tim=92s emails on how CNAM does not work today at:=0A= https://mailarchive.ietf.org/arch/msg/cnit/D7JeNaGHOjHJAaFi2jeT2Y_C1oA=0A= Now imagine the third-party number-to-name translation service DOES want to= be evil. Yuck!=0A= =0A= Nothing in what I have seen in CNIT would *prevent* third-party number vali= dation services or third-party number-to-name services from offering such s= ervices. They work today: at my endpoint, *I* decide to do another dip with= these services. However, I see nothing in CNIT that would be sensible for = such a service to be in the *signaling* path.=0A= =0A= =0A= Reason #2: if the user or the user=92s service provider is in control of in= serting the signed calling name, then all of the user privacy arguments eva= porate. Who cares that a real calling name, THAT THE USER WANTS DISPLAYED, = gets sent in the signaling path? First of all, it is up to the USER to send= the information. Second, yes, this is different than today=92s North Ameri= can SS7 configuration. SURPRISE! We are talking SIP, not SS7. We can do wha= tever we want. Given we have thirty years of knowing sending only the numbe= r and later asking for the name is hopelessly broken, why would we want to = replicate that? Remember the mantra: =93User Control is Good."=0A= =0A= It is unquestionably true that we are making it easier for amateurs to find= out the calling name by sniffing the signaling. This says they have access= to unencrypted signaling (probably already a problem). Moreover, it is say= ing that they have access to the signaling and yet they DO NOT have any acc= ess to a number-to-name translation data base. I would offer the latter is = a 0.0000000001% probability. If they have the sophistication to crack sips = (OK, not too hard, but not trivial), they have access to any of the public = number-to-name data bases out there.=0A= =0A= If we do want to protect from, for example, nation-states, we could encrypt= the name itself with the public key of the called party. If someone is tha= t paranoid, they will not mind the setup penalty in the signaling. I doubt = anyone would use it, but if that is what it takes to get chartered, I=92ve = got students who can write an I-D that nobody will use but will get a publi= cation ;-)=0A= =0A= From nobody Mon Jun 15 15:11:31 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891801B2C5E for ; Mon, 15 Jun 2015 15:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-qzpZmBCHp1 for ; Mon, 15 Jun 2015 15:11:29 -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 DA2231B2C5D for ; Mon, 15 Jun 2015 15:11:28 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tADGHMBAAITkHRAAICivQADuTr0w= Date: Mon, 15 Jun 2015 22:11:26 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net>, <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> , <2B0F677F0B95454297753F58D4A07FA30279326E8D@FHDP1LUMXC7V31.us.one.verizon.com> , <2B0F677F0B95454297753F58D4A07FA30279326EC8@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30279326EC8@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 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 22:11:30 -0000 Agreed that the terminating carrier can provide added value, e.g., by linki= ng to other information. You could imagine mapping numbers to BBB informati= on, or databases or registered charities, or Yelp... I am somewhat surprise= d that this isn't happening already more broadly.=0A= =0A= ________________________________________=0A= From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]=0A= Sent: Sunday, June 14, 2015 1:58 PM=0A= To: Henning Schulzrinne=0A= Cc: cnit@ietf.org=0A= Subject: RE: [cnit] CNIT Charter bashing..=0A= =0A= Henning,=0A= =0A= I'm not sure 'carrier B' would in the "in-band case" have no incentive to u= se a 3rd party service. It might be that the 3rd party service provides ad= ditional information and/or is considered more trustworthy than whoever pro= vided the in-band information. We can (and I hope will) change the incenti= ves. I think it would be a reasonable objective to carry whatever content = is deemed "necessary" to serve the public, in-band. If people want to oper= ate databases full of calling party's cat pictures, and Carrier B wants to = provide this to their customer (or allow their customer to obtain it themse= lves, e.g., provide them a link to it) that's all OK with me.=0A= =0A= I agree with you about the importance of being able to know unambiguously, = who inserted the information.=0A= =0A= Tim=0A= From nobody Mon Jun 15 15:52:31 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38B31A1B0E for ; Mon, 15 Jun 2015 15:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPApP0lgP9vI for ; Mon, 15 Jun 2015 15:52:28 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 61DB51A1B16 for ; Mon, 15 Jun 2015 15:52:25 -0700 (PDT) Received: (qmail 393 invoked by uid 0); 15 Jun 2015 22:52:18 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 15 Jun 2015 22:52:18 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id gsRL1q0041MNPNq01sRP1h; Mon, 15 Jun 2015 22:25:26 -0600 X-Authority-Analysis: v=2.1 cv=Bb1LjNd2 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=ZsyXEVtvAAAA:8 a=48vgC7mUAAAA:8 a=LGD2e4KDdQpSDvPiFBcA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=TL+yFyZup++U4eZiDemLhHczuv563LuWbUqSE7AL9kU=; b=MIcCvxQw4ru2cCyLfCj5juwK9tgix2CVmqjrbwjRtWGEZG+SSOhdx3Rja56LwHgTpwvjDHKTiJ+ubMhhYewAg3N5FDji5ybNqUT7wV2tXTnIqrhXIJ5CISaAfOflSnI4; Received: from [108.56.131.149] (port=57475 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z4cvM-0004Ry-2h; Mon, 15 Jun 2015 16:32:12 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Mon, 15 Jun 2015 18:32:07 -0400 From: Richard Shockey To: Henning Schulzrinne , "Dwight, Timothy M (Tim)" Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326E8D@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326EC8@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 22:52:29 -0000 Tim Henning .. This is uniquely timely and important because the SIP Forum is at this moment attempting to revise its SIPConnect Recommendation for PBX / hosted to SSP interface where the data may be originated by the enterprise and it needs to be treated in some way by the NNI. (hopefully maybe not stripped if its seen in the FROM or P-AI) Its a complication but not insurmountable. It clearly shows we need to rethink the charter and look at some baby steps vs demanding that all the STIR like mechanisms be in place before there is progress. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 6/15/15, 6:11 PM, "Henning Schulzrinne" wrote: >Agreed that the terminating carrier can provide added value, e.g., by >linking to other information. You could imagine mapping numbers to BBB >information, or databases or registered charities, or Yelp... I am >somewhat surprised that this isn't happening already more broadly. > >________________________________________ >From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] >Sent: Sunday, June 14, 2015 1:58 PM >To: Henning Schulzrinne >Cc: cnit@ietf.org >Subject: RE: [cnit] CNIT Charter bashing.. > >Henning, > >I'm not sure 'carrier B' would in the "in-band case" have no incentive to >use a 3rd party service. It might be that the 3rd party service provides >additional information and/or is considered more trustworthy than whoever >provided the in-band information. We can (and I hope will) change the >incentives. I think it would be a reasonable objective to carry whatever >content is deemed "necessary" to serve the public, in-band. If people >want to operate databases full of calling party's cat pictures, and >Carrier B wants to provide this to their customer (or allow their >customer to obtain it themselves, e.g., provide them a link to it) that's >all OK with me. > >I agree with you about the importance of being able to know >unambiguously, who inserted the information. > >Tim > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit From nobody Tue Jun 16 08:52:50 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8A61B3AC9 for ; Tue, 16 Jun 2015 08:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.404 X-Spam-Level: *** X-Spam-Status: No, score=3.404 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_PHARMACY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNwUbYLvvR6L for ; Tue, 16 Jun 2015 08:52:48 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73ED11B3B07 for ; Tue, 16 Jun 2015 08:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434469956; x=1466005956; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=giVp2EWStYKsrBOA6JX6z7HwDuVKgkrqtDCHiRqSqdE=; b=JdAgMqxEGcAWbMEofAv6lLi3SnQJ0iQ5qQXwKsMEHzVWX6FyPeGtsQ+J XHP5Cp3rzrHZR9X5ULi1ofDS/5rASEDqKrgQ4W9EymosAUJ/zPFDzWGuh h9Y+K5HTXHPNoZ+Pc1Y3sUbQ/rjvOFx/rE2sKtvQQE2eYGNUAhnInDBVi E=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 16 Jun 2015 15:52:35 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.13,627,1427760000"; d="scan'208";a="29175460" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 16 Jun 2015 15:52:34 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Tue, 16 Jun 2015 11:52:33 -0400 To: Henning Schulzrinne , Eric Burger , "cnit@ietf.org" Date: Tue, 16 Jun 2015 11:52:32 -0400 Thread-Topic: [cnit] Who says I am me? I say it is me. I have no reason to trust you. Thread-Index: AQHQptHgjGJJjViUs0yXviD2b11ltJ2uE5LsgAEYf9A= Message-ID: <2B0F677F0B95454297753F58D4A07FA30279408FAF@FHDP1LUMXC7V31.us.one.verizon.com> References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <31D54523-375B-42D6-A621-28A009E2DF20@brianrosen.net> , <1B18AE2F-C2C7-4B0B-A3FA-08F7BD90BD38@standardstrack.com> In-Reply-To: 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 Archived-At: Subject: Re: [cnit] Who says I am me? I say it is me. I have no reason to trust you. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2015 15:52:50 -0000 Henning, What you describe sounds like it would facilitate robocalls - appending to = a call from a random pharmacy, an advertisement on behalf of the caller. I= 'm sure that's not what you intend. I think it would be more useful to the called party to know that the call i= s from a specific pharmacy with which they are familiar. If they're famili= ar with it they already know what type of entity it is. Tim -----Original Message----- From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, June 15, 2015 4:39 PM To: Eric Burger; cnit@ietf.org Subject: Re: [cnit] Who says I am me? I say it is me. I have no reason to t= rust you. I've said this before, but I think in many cases, the name is less importan= t than some verifiable property. For example, apparently some durable medic= al equipment fraudsters use the display name MEDCARE. From a quick trademar= k search, there actually is a legitimate business with that name (Medcare D= iscount Pharmacy), but validating the name does not always protect against = user confusion. A flag that shows that this is a legitimate, licensed pharm= acy would be more useful and that type of validation can be provided by any= number of third-party entities. The number of such categories is very smal= l since the number of businesses that need to be state/federally-licensed a= nd that care about validation (your nail salon or florist may need a licens= e but is unlikely to care about tagging their phone calls) isn't that large= . Thus, validating names is useful, but 100% accuracy validation may be very = difficult to achieve (given the need for brevity and practical limitations = of sources of information in the age of IRS KBA bypass.) For example, I hav= e a credit card that uses a non-state-registered name (xyz consulting) and = a billing address validation might accept this as legitimate. As a side note, I recently used Dun&Bradstreet to access and modify my corp= orate (DUNS) record for a small entity I run. For their KBA, all I needed t= o know was the registered address, landline phone number and the last two d= igits of the SSN, plus some "did you ever use some-ridiculous-first-name" q= uestion. Not very confidence-inducing. Given that this small business has n= o credit history, this is not surprising - there just isn't much to work wi= th that isn't listed on the certificate of incorporation. Practically speaking, most names aren't worth faking. There seems little be= nefit to pretending to be Joe's Pizza or Adam Smith if you're not, except f= or pranks ("Did you just order 100 anchovy pizzas?"). Thus, protecting high= -value names is likely more productive, such as those of government agencie= s, utilities/carriers or financial institutions.=20 ________________________________________ From: cnit [cnit-bounces@ietf.org] on behalf of Eric Burger [eburger@standa= rdstrack.com] Sent: Sunday, June 14, 2015 2:42 PM To: cnit@ietf.org Subject: [cnit] Who says I am me? I say it is me. I have no reason to trust= you. [changing the subject to be meaningful, kind of like a CNAM...] I fully agree with Henning here for two reasons. Reason #1: the point of CNIT, STIR, MODERN, et al. is we are not dooming ou= rselves to simply do IP versions of SS7. We already have that. My expectati= on is for 99% of the use of CNIT, the calling name will be inserted by the = end user equipment (enterprise PBX or SIP phones) or the carrier service pr= ovider (mobile, wireline replacement, broadband cable telephony, etc.). What do we do with the 1% of calls that will come from non-service provider= endpoints? E.g., what if you had an open source Foo Fone? The easy answer = would be to say you are in a self-signed certificate bind. If you want your= name to pop up correctly, pay for a service that will vouch for you. Howev= er, the IETF does not mandate business models. So, one could envision some = sort of PGP-like web of trust. However, that is on the signing of the name,= NOT on the number-to-name translation. Let us be realistic: if I cannot tr= ust the veracity of the name, I cannot trust the veracity of the calling nu= mber, so all bets are off anyway. I thus see zero need for or value from some third-party number-to-name tran= slation service. This simply replicates all of the evils of the current sys= tem when the players are NOT trying to be evil, but only stupid. As an exam= ple, see Tim's emails on how CNAM does not work today at: https://mailarchive.ietf.org/arch/msg/cnit/D7JeNaGHOjHJAaFi2jeT2Y_C1oA Now imagine the third-party number-to-name translation service DOES want to= be evil. Yuck! Nothing in what I have seen in CNIT would *prevent* third-party number vali= dation services or third-party number-to-name services from offering such s= ervices. They work today: at my endpoint, *I* decide to do another dip with= these services. However, I see nothing in CNIT that would be sensible for = such a service to be in the *signaling* path. Reason #2: if the user or the user's service provider is in control of inse= rting the signed calling name, then all of the user privacy arguments evapo= rate. Who cares that a real calling name, THAT THE USER WANTS DISPLAYED, ge= ts sent in the signaling path? First of all, it is up to the USER to send t= he information. Second, yes, this is different than today's North American = SS7 configuration. SURPRISE! We are talking SIP, not SS7. We can do whateve= r we want. Given we have thirty years of knowing sending only the number an= d later asking for the name is hopelessly broken, why would we want to repl= icate that? Remember the mantra: "User Control is Good." It is unquestionably true that we are making it easier for amateurs to find= out the calling name by sniffing the signaling. This says they have access= to unencrypted signaling (probably already a problem). Moreover, it is say= ing that they have access to the signaling and yet they DO NOT have any acc= ess to a number-to-name translation data base. I would offer the latter is = a 0.0000000001% probability. If they have the sophistication to crack sips = (OK, not too hard, but not trivial), they have access to any of the public = number-to-name data bases out there. If we do want to protect from, for example, nation-states, we could encrypt= the name itself with the public key of the called party. If someone is tha= t paranoid, they will not mind the setup penalty in the signaling. I doubt = anyone would use it, but if that is what it takes to get chartered, I've go= t students who can write an I-D that nobody will use but will get a publica= tion ;-) _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From nobody Wed Jun 17 10:32:49 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214601B2C35 for ; Wed, 17 Jun 2015 10:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.213 X-Spam-Level: **** X-Spam-Status: No, score=4.213 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_50=0.8, GB_PHARMACY=1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-0XJi8iUjaN for ; Wed, 17 Jun 2015 10:32:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF3B1B2BD3 for ; Wed, 17 Jun 2015 10:32:36 -0700 (PDT) Received: from BY2FFO11FD047.protection.gbl (10.1.14.30) by BY2FFO11HUB005.protection.gbl (10.1.14.163) with Microsoft SMTP Server (TLS) id 15.1.190.9; Wed, 17 Jun 2015 17:32:20 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BY2FFO11FD047.mail.protection.outlook.com (10.1.15.175) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Wed, 17 Jun 2015 17:32:20 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5HH9iI2034569; Wed, 17 Jun 2015 12:32:19 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm1.corp.sprint.com with ESMTP id 1v0j5bmxrj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Jun 2015 12:32:19 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 17 Jun 2015 13:32:17 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Wed, 17 Jun 2015 12:32:17 -0500 From: "Gorman, Pierce A [CTO]" To: "Dwight, Timothy M (Tim)" , "Henning Schulzrinne" , Eric Burger , "cnit@ietf.org" Thread-Topic: [cnit] Who says I am me? I say it is me. I have no reason to trust you. Thread-Index: AdCpI40wA3qVYIRqTM2jMyZGsgFDGg== Date: Wed, 17 Jun 2015 17:32:16 +0000 Message-ID: <3c25cf396bb247509ed856353c33621f@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD047; 1:8MXpaKH4ikUSjVmS1JMDt6/yBTimKMJd/2KuqxFkBO7J3gn13uec35pXBZLsRoHmgurWDw9FSBN8T71bT+IiiueQfiw7QVRIOaSWyQyuS6Nn2/D8agyAejYmgk/84oJ3JGa2ZWSgwNJ3qwo9e89iQeUGBCkV8fEHkydbaCjmy7WUiwrQdZuoKp4kB7aRc+XFhDinb8cS2VB53t8nTiaM18rVvpJ99SZsCMHhqlcrhJPY9LJF9TcHgvyjZUOK+MaqC5P31i1ZiGghHquO+mLRIh3vh49WGKycBooM3Kq8H9XWKr1OJG5DdDV6iHqcXo2evGDs9nLmxiEq9cHvCckqWQ== X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(448002)(505084002)(189002)(199003)(377454003)(13464003)(85326001)(106466001)(15975445007)(102836002)(33646002)(46406003)(19580395003)(50466002)(19580405001)(108616004)(6806004)(2656002)(87936001)(86362001)(47776003)(62966003)(77156002)(97756001)(24736003)(189998001)(92566002)(107886002)(5001960100002)(5250100002)(2501003)(54356999)(5003600100002)(2900100001)(46102003)(23726002)(50986999)(81156007)(5001770100001)(574934001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB005; H:plsapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB005; 2:bFluJXXlRT6Uuft68Wm9Ma7yejEaX8Q4geUJ5bKd4HfrPMo3NuNFxJGbf1Hh8cU5; 2:UiX/MBPz1KrSlyVcuZv6sbzUOS68JYMHDKOolsFQ8OlOl9KtNYcjrftN94ns5wDCDPYzhOABGzFm0Y8I0pLMn+XJ979oSGrHdechBfeSp+mwuD1pVFLVeeJmBQwsaBCrScQHXVXwVXVJkmWxp/i2KKZpyUxQntfWxc5BUkDKelkgSKbzLSGK9p2PyZ1Gkvsbx2X3sxThedU/gwa1l3Ay1RFCpVeRSJ4z5Uz7B0rjnytkr4NDZLZE7/72iB2lDbdz; 6:aqmugRiUX89ixtjr11XM+3worWxYBEdJrTGP/3lWH3yG5J/PLSVdXfTZHGhlezi7U1kErPx89PKJyAp9yWRtMGEBmfD7EPxDy5OOE7n3Lbs6GpDTF+/yCrxJ1Ucuk7dZZa6vndUehYfNRTbsgHiNgdfibbW9ThzXEmOZuA72sjx+QaCWBWmHV6XBnCdmEdo3ktGbEIi86hiEmY0XLibrqaQsKmsg2TiTt2bo3gJCxIdSGGplHU9WM9qPU3irTV0x; 3:eRPQly/RU97B2mwXjFId9HcCfybCig2qBOcFA66x7VDBb+ZU4RKhNl+QasIH5Ro/Bys8Tcm7+rq4bfGyIdMvHZMy1aln9eoScfEpQsPWVzidS4dZ3oZNyNHsvMcpuJsWOeCw2hDOnufgk7ehDNMhmTLtPNLzcpheq6Z6Mw40/dM2+4QQN/ST2Y8/1HH2VA5G66US/+NAWp1Fa1VqsulPSRacAgb3KrGm1wZscX5FeUGmMDU7xZ1vtBGx02AAGshm0nCD7hHPgkbnhOd5UCmvyl5nJq2DKOAln+pzHb3FOqAo3OmQqIG3st8HQO72+Tir X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB005; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BY2FFO11HUB005; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB005; X-Forefront-PRVS: 0610D16BBE X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB005; 9:HGcjEhVlvaHCLKFLTCeHXM7eYj9AUhVwQOdxkpnFL?= =?us-ascii?Q?uyAM669hS7lxdRDpvj5wxQhM0KdMZk7WaW5ph3iQzeX5usDiFSOftNKw41pD?= =?us-ascii?Q?7R4wnjYYFwIiQFuqY3XnBLLrl12na75AUW56VVbkH0QoOtdfuuA9fAUug5Ah?= =?us-ascii?Q?VIdv40DGpBKl3PEq2xoxEN4rAIrLjPIFIztcAm/SKphlCjUftlYZjFRBZZpS?= =?us-ascii?Q?LaTDSfP/2kdC7EMIvtUbGPzzyKdmo/LxHjc2pwzyPCxr4SCi4bvA6mhCnBAp?= =?us-ascii?Q?uVAiY1YudGVzZZoXYDyhL6OSy8ia3CUCBt9Da3A6ou4AXnplNeYxhxHo2ktb?= =?us-ascii?Q?obP1gZzr11pJov95eI38HXdepuAC+eCb87eUYbizx147/TxuTgRQ3snUBdSI?= =?us-ascii?Q?+xh/BqxvegHlx6fGU0Fuz/rkQZXP5WMO7gewnIioBqUzB1TyyKv2123RQ7x4?= =?us-ascii?Q?CvPhDJ6W0+Yw2xVjYNKU3fiTShV8/XzSEgAMEekJUEBfUP6ODiqBVzJUuw4m?= =?us-ascii?Q?24noYoGZNY0RGx37oVNl9bG3Jwdv62z8/gHw70cu4qNSlsGQkTLUELW/JvAE?= =?us-ascii?Q?L9bd2pvWQ4WzrYjds+yL/54MBgX6MKu3gw0XKzDpgPvRfAMBJgim/dpVBkUO?= =?us-ascii?Q?ueY7rlq4avaoCLzs3UbenFIoOn7ShiYgJWBMNkpEmnTn+43WJRYdZccVrZE8?= =?us-ascii?Q?iC/W0SodCgELSVsrBVFIATuv6TTO8++WctfgcuawWLWj3qIdLT04s4tmI0YL?= =?us-ascii?Q?DUoU36wNm8gKcLt6+toaojkN0MnVwYqtUifBEQ8zgcv+xc7ALuhW2vaXUO3d?= =?us-ascii?Q?Z/qB5PO8LlQl2ETHDov6SYwCBN0FY8fbHm/HDDIyh1fT7TZye6WbGSi17bc8?= =?us-ascii?Q?3DvKis+eLwfinUpLWAiNgiEcUXaZP/CaVWVFOCX0TBpHiL+m4PQ/VOIzcOQA?= =?us-ascii?Q?VGdrPpjo9TaaVhgAiXKg/Ne9n2SVjiLxbJcvsbOa9pGulAOHWgiceDekDhED?= =?us-ascii?Q?7HbEYCMabONiGPwa3MjESqYnoIU3KO/ur8nDXB/hrDPV/5W8O9aF69+YY+3y?= =?us-ascii?Q?1uFCll6GOcneaFDEplSCwNOOcuAn8C30BP8cTCg7qQWMa3/rg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB005; 3:LHnCSwzmg9Lyr4A4N1TlWVmNy7mhamiylf3ptgpCFZoprG+/DMXFzBL18Lb++axlEBqWBLXhuqWb9zHjxNhwHIgGQgyY1isyaaE4yK5gXm3Dpxu2u4PsigO4pfkT2In7xGwZbMaVy6Ow7bjIejyoag==; 10:qixVsaOU8+33G1nIKbiy4pWs9I3F1hSXeqMkkJFzmex/J4RJ4zWaWPXeUpmy5Mfjcvkpv+WUSOUgAITeg797bzd1XsiQCNyEMbXpDSf7nyA= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2015 17:32:20.1514 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB005 Archived-At: Subject: Re: [cnit] Who says I am me? I say it is me. I have no reason to trust you. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2015 17:32:46 -0000 " The number of such categories is very small since the number of businesse= s that need to be state/federally-licensed and that care about validation (= your nail salon or florist may need a license but is unlikely to care about= tagging their phone calls) isn't that large." - H. Schulzrinne Interesting assumption. Would it be appropriate to initiate a study to ver= ify whether the assumption was true? Is the only category of concern those= businesses which require state and federal licensing? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: June 16, 2015 10:53 AM To: Henning Schulzrinne; Eric Burger; cnit@ietf.org Subject: Re: [cnit] Who says I am me? I say it is me. I have no reason to t= rust you. Henning, What you describe sounds like it would facilitate robocalls - appending to = a call from a random pharmacy, an advertisement on behalf of the caller. I= 'm sure that's not what you intend. I think it would be more useful to the called party to know that the call i= s from a specific pharmacy with which they are familiar. If they're famili= ar with it they already know what type of entity it is. Tim -----Original Message----- From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, June 15, 2015 4:39 PM To: Eric Burger; cnit@ietf.org Subject: Re: [cnit] Who says I am me? I say it is me. I have no reason to t= rust you. I've said this before, but I think in many cases, the name is less importan= t than some verifiable property. For example, apparently some durable medic= al equipment fraudsters use the display name MEDCARE. From a quick trademar= k search, there actually is a legitimate business with that name (Medcare D= iscount Pharmacy), but validating the name does not always protect against = user confusion. A flag that shows that this is a legitimate, licensed pharm= acy would be more useful and that type of validation can be provided by any= number of third-party entities. The number of such categories is very smal= l since the number of businesses that need to be state/federally-licensed a= nd that care about validation (your nail salon or florist may need a licens= e but is unlikely to care about tagging their phone calls) isn't that large= . Thus, validating names is useful, but 100% accuracy validation may be very = difficult to achieve (given the need for brevity and practical limitations = of sources of information in the age of IRS KBA bypass.) For example, I hav= e a credit card that uses a non-state-registered name (xyz consulting) and = a billing address validation might accept this as legitimate. As a side note, I recently used Dun&Bradstreet to access and modify my corp= orate (DUNS) record for a small entity I run. For their KBA, all I needed t= o know was the registered address, landline phone number and the last two d= igits of the SSN, plus some "did you ever use some-ridiculous-first-name" q= uestion. Not very confidence-inducing. Given that this small business has n= o credit history, this is not surprising - there just isn't much to work wi= th that isn't listed on the certificate of incorporation. Practically speaking, most names aren't worth faking. There seems little be= nefit to pretending to be Joe's Pizza or Adam Smith if you're not, except f= or pranks ("Did you just order 100 anchovy pizzas?"). Thus, protecting high= -value names is likely more productive, such as those of government agencie= s, utilities/carriers or financial institutions. ________________________________________ From: cnit [cnit-bounces@ietf.org] on behalf of Eric Burger [eburger@standa= rdstrack.com] Sent: Sunday, June 14, 2015 2:42 PM To: cnit@ietf.org Subject: [cnit] Who says I am me? I say it is me. I have no reason to trust= you. [changing the subject to be meaningful, kind of like a CNAM...] I fully agree with Henning here for two reasons. Reason #1: the point of CNIT, STIR, MODERN, et al. is we are not dooming ou= rselves to simply do IP versions of SS7. We already have that. My expectati= on is for 99% of the use of CNIT, the calling name will be inserted by the = end user equipment (enterprise PBX or SIP phones) or the carrier service pr= ovider (mobile, wireline replacement, broadband cable telephony, etc.). What do we do with the 1% of calls that will come from non-service provider= endpoints? E.g., what if you had an open source Foo Fone? The easy answer = would be to say you are in a self-signed certificate bind. If you want your= name to pop up correctly, pay for a service that will vouch for you. Howev= er, the IETF does not mandate business models. So, one could envision some = sort of PGP-like web of trust. However, that is on the signing of the name,= NOT on the number-to-name translation. Let us be realistic: if I cannot tr= ust the veracity of the name, I cannot trust the veracity of the calling nu= mber, so all bets are off anyway. I thus see zero need for or value from some third-party number-to-name tran= slation service. This simply replicates all of the evils of the current sys= tem when the players are NOT trying to be evil, but only stupid. As an exam= ple, see Tim's emails on how CNAM does not work today at: https://mailarchive.ietf.org/arch/msg/cnit/D7JeNaGHOjHJAaFi2jeT2Y_C1oA Now imagine the third-party number-to-name translation service DOES want to= be evil. Yuck! Nothing in what I have seen in CNIT would *prevent* third-party number vali= dation services or third-party number-to-name services from offering such s= ervices. They work today: at my endpoint, *I* decide to do another dip with= these services. However, I see nothing in CNIT that would be sensible for = such a service to be in the *signaling* path. Reason #2: if the user or the user's service provider is in control of inse= rting the signed calling name, then all of the user privacy arguments evapo= rate. Who cares that a real calling name, THAT THE USER WANTS DISPLAYED, ge= ts sent in the signaling path? First of all, it is up to the USER to send t= he information. Second, yes, this is different than today's North American = SS7 configuration. SURPRISE! We are talking SIP, not SS7. We can do whateve= r we want. Given we have thirty years of knowing sending only the number an= d later asking for the name is hopelessly broken, why would we want to repl= icate that? Remember the mantra: "User Control is Good." It is unquestionably true that we are making it easier for amateurs to find= out the calling name by sniffing the signaling. This says they have access= to unencrypted signaling (probably already a problem). Moreover, it is say= ing that they have access to the signaling and yet they DO NOT have any acc= ess to a number-to-name translation data base. I would offer the latter is = a 0.0000000001% probability. If they have the sophistication to crack sips = (OK, not too hard, but not trivial), they have access to any of the public = number-to-name data bases out there. If we do want to protect from, for example, nation-states, we could encrypt= the name itself with the public key of the called party. If someone is tha= t paranoid, they will not mind the setup penalty in the signaling. I doubt = anyone would use it, but if that is what it takes to get chartered, I've go= t students who can write an I-D that nobody will use but will get a publica= tion ;-) _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Jun 29 16:47:39 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408D91B3624 for ; Mon, 29 Jun 2015 16:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.567 X-Spam-Level: X-Spam-Status: No, score=-99.567 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3olIsJ-BFHd6 for ; Mon, 29 Jun 2015 16:47:36 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2C41B3622 for ; Mon, 29 Jun 2015 16:47:36 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t5TNlJ24007922; Mon, 29 Jun 2015 19:47:34 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vb5y6ru5y-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Jun 2015 19:47:34 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 19:47:32 -0400 From: "Peterson, Jon" To: Richard Shockey , Henning Schulzrinne , "Dwight, Timothy M (Tim)" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27KGEooroT50KUThK45F2vPZ2nvtOAgAAcbYCAAAFnAIABDhMAgAA9LQCAAAZIgIAAAREAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgIAANESAgAGXr4CAAP2pAIAAQ9wAgAHZCwCAAAXIgIAVoFeA Date: Mon, 29 Jun 2015 23:47:31 +0000 Message-ID: References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326E8D@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326EC8@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.128.52] Content-Type: text/plain; charset="utf-8" Content-ID: <3A69838A6127824F841DD1CABF6A3B2F@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-29_05:2015-06-29,2015-06-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506290385 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 23:47:38 -0000 DQpJdCdzIG5vdCBjbGVhciB0byBtZSB0aGF0IHdlIG5lZWQgYW55IFNUSVItbGlrZSBtZWNoYW5p c21zIHRvIGJlIGluIHBsYWNlDQpiZWZvcmUgZW1iYXJraW5nIG9uIENOSVQuIFdoYXQgSSd2ZSBi YXNpY2FsbHkgd3JpdHRlbiBpbiB0byBTVElSIGlzIGFuDQpleHRlbnNpb24gZmllbGQgdGhhdCBD TklUIGNvdWxkIHVzZSB0byBob29rIGludG8gdGhlIHNpZ25hdHVyZS4gQWxsIGl0DQp3b3VsZCBy ZXF1aXJlIGlzIHRoYXQgQ05JVCBjcmVhdGUgYSBzcGVjaWZpY2F0aW9uIChhcyBjdXJyZW50bHkg d3JpdHRlbiwgYQ0KU3RhbmRhcmRzIFRyYWNrIFJGQykgdGhhdCBkZXNpZ25hdGVzIHdoYXQgdGhl IGZpZWxkKHMpIHRoYXQgd2lsbCBiZQ0Kc2lnbmVkLCBhbmQgdGhlbiB0aGUgbmVjZXNzYXJ5IHBy b2NlZHVyZXMgYW5kIHNvIG9uLg0KDQpGdW5kYW1lbnRhbGx5IEkgYWdyZWUgdGhhdCBob29raW5n IENOSVQgaW50byBTVElSIHdpbGwgb25seSBwcm92aWRlIHBhcnQNCm9mIGEgc29sdXRpb24uIFRo ZXJlIGFyZSBnb2luZyB0byBiZSBjYXNlcyB3aGVuIHRoZSBlbnRpdHkgdGhhdCBvcmlnaW5hdGVz DQoob3Igc2lnbnMpIFNJUCBzaWduYWxpbmcgaXMgbm90IGdvaW5nIHRvIGJlIHRoZSByaWdodCBw YXJ0eSB0byBhdHRlc3QgdG8NCnRoZSBwcm9wZXIgZGlzcGxheSBuYW1lIGZvciBhIHVzZXIuDQoN CkFyY2hpdGVjdHVyYWxseSwgd2hhdCBJJ2QgcHJvYmFibHkgcHJlZmVyIGlzIHRvIHRoaW5rIGFi b3V0IHRoaXMgd29yayBhcw0KZGVzaWduaW5nIGEgc21hbGwsIGJ1dCBzb21ld2hhdCBleHRlbnNp YmxlIGJsb2NrIG9mIGluZm9ybWF0aW9uIHdoaWNoDQpzb21lb25lIGNvdWxkIHNpZ24uIFNtYWxs IGVub3VnaCB0aGF0IGl0IGNvdWxkIGZpdCBpbiBhIFNJUCBtZXNzYWdlLCBhbmQNCmJlIHNpZ25l ZCB0aGVyZSBieSBob29raW5nIGludG8gdGhlIFNUSVIgZXh0ZW5zaW9uIGZpZWxkLiBCdXQgYWxz bw0Kc29tZXRoaW5nIHRoYXQgY291bGQgYmUgY2FycmllZCBieSBhbiBleHRlcm5hbCBwcm90b2Nv bCBmb3IgdGhvc2UgY2FzZXMNCndoZW4gdGhlIFNUSVIgc2lnbmVyIG1pZ2h0IG5vdCBiZSB0aGUg YXV0aG9yaXR5IG9uIHRoZSBkaXNwbGF5IG5hbWUuIE1heWJlDQp0aGUgU1RJUiBzaWduZXIgd291 bGQgZmV0Y2ggaXQgdmlhIHRoYXQgZXh0ZXJuYWwgcHJvdG9jb2wsIGFuZCB0aGVuIHBhc3MNCmFs b25nIHRoZSBzaWduYXR1cmUgb2YgdGhlIGF1dGhvcml0eSBmcm9tIHdob20gdGhleSBhY3F1aXJl ZCBpdCwgaW4NCmFkZGl0aW9uIHRvIHNpZ25pbmcgaXQgdGhlbXNlbHZlcy4gT3IgbWF5YmUgdGhl IHJlY2lwaWVudCB3b3VsZCB1c2UgdGhlDQpleHRlcm5hbCBwcm90b2NvbCBpZiB0aGVyZSBpcyBu byBTVElSIGhvb2suIElmIHdlIGJ1aWxkIGEgc3lzdGVtIHdpdGgNCnJvdWdobHkgdGhvc2UgcXVh bGl0aWVzLCBhbmQgZm9jdXMgbW9yZSBvbiB0aGUgaW5mbyBibG9jayB0aGFuIG9uIGhvdyBpdA0K Z2V0cyB0cmFuc3BvcnRlZCBuZWNlc3NhcmlseSwgSSB0aGluayB3ZSdsbCBkbyBzb21lIHZhbHVh YmxlIHdvcmsuDQoNCkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgSW5jLg0KDQpPbiA2LzE1LzE1LCAz OjMyIFBNLCAiUmljaGFyZCBTaG9ja2V5IiA8cmljaGFyZEBzaG9ja2V5LnVzPiB3cm90ZToNCg0K Pg0KPlRpbSBIZW5uaW5nIC4uIFRoaXMgaXMgdW5pcXVlbHkgdGltZWx5IGFuZCBpbXBvcnRhbnQg YmVjYXVzZSB0aGUgU0lQIEZvcnVtDQo+aXMgYXQgdGhpcyBtb21lbnQgYXR0ZW1wdGluZyB0byBy ZXZpc2UgaXRzIFNJUENvbm5lY3QgUmVjb21tZW5kYXRpb24gZm9yDQo+UEJYIC8gaG9zdGVkIHRv IFNTUCBpbnRlcmZhY2Ugd2hlcmUgdGhlIGRhdGEgbWF5IGJlIG9yaWdpbmF0ZWQgYnkgdGhlDQo+ ZW50ZXJwcmlzZSBhbmQgaXQgbmVlZHMgdG8gYmUgdHJlYXRlZCBpbiBzb21lIHdheSBieSB0aGUg Tk5JLiAoaG9wZWZ1bGx5DQo+bWF5YmUgbm90IHN0cmlwcGVkIGlmIGl0cyBzZWVuIGluIHRoZSBG Uk9NIG9yIFAtQUkpDQo+DQo+SXRzIGEgY29tcGxpY2F0aW9uIGJ1dCBub3QgaW5zdXJtb3VudGFi bGUuIEl0IGNsZWFybHkgc2hvd3Mgd2UgbmVlZCB0bw0KPnJldGhpbmsgdGhlIGNoYXJ0ZXIgYW5k IGxvb2sgYXQgc29tZSBiYWJ5IHN0ZXBzIHZzIGRlbWFuZGluZyB0aGF0IGFsbCB0aGUNCj5TVElS IGxpa2UgbWVjaGFuaXNtcyBiZSBpbiBwbGFjZSBiZWZvcmUgdGhlcmUgaXMgcHJvZ3Jlc3MuDQo+ DQo+DQo+DQo+4oC5IA0KPlJpY2hhcmQgU2hvY2tleQ0KPlNob2NrZXkgQ29uc3VsdGluZyBMTEMN Cj5DaGFpcm1hbiBvZiB0aGUgQm9hcmQgU0lQIEZvcnVtDQo+d3d3LnNob2NrZXkudXMNCj53d3cu c2lwZm9ydW0ub3JnDQo+cmljaGFyZDxhdD5zaG9ja2V5LnVzDQo+U2t5cGUtTGlua2VkaW4tRmFj ZWJvb2sgcnNob2NrZXkxMDENCj5QU1ROICsxIDcwMy01OTMtMjY4Mw0KPg0KPg0KPg0KPg0KPg0K Pk9uIDYvMTUvMTUsIDY6MTEgUE0sICJIZW5uaW5nIFNjaHVsenJpbm5lIiA8SGVubmluZy5TY2h1 bHpyaW5uZUBmY2MuZ292Pg0KPndyb3RlOg0KPg0KPj5BZ3JlZWQgdGhhdCB0aGUgdGVybWluYXRp bmcgY2FycmllciBjYW4gcHJvdmlkZSBhZGRlZCB2YWx1ZSwgZS5nLiwgYnkNCj4+bGlua2luZyB0 byBvdGhlciBpbmZvcm1hdGlvbi4gWW91IGNvdWxkIGltYWdpbmUgbWFwcGluZyBudW1iZXJzIHRv IEJCQg0KPj5pbmZvcm1hdGlvbiwgb3IgZGF0YWJhc2VzIG9yIHJlZ2lzdGVyZWQgY2hhcml0aWVz LCBvciBZZWxwLi4uIEkgYW0NCj4+c29tZXdoYXQgc3VycHJpc2VkIHRoYXQgdGhpcyBpc24ndCBo YXBwZW5pbmcgYWxyZWFkeSBtb3JlIGJyb2FkbHkuDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PkZyb206IER3aWdodCwgVGltb3RoeSBNIChUaW0pIFt0 aW1vdGh5LmR3aWdodEB2ZXJpem9uLmNvbV0NCj4+U2VudDogU3VuZGF5LCBKdW5lIDE0LCAyMDE1 IDE6NTggUE0NCj4+VG86IEhlbm5pbmcgU2NodWx6cmlubmUNCj4+Q2M6IGNuaXRAaWV0Zi5vcmcN Cj4+U3ViamVjdDogUkU6IFtjbml0XSBDTklUIENoYXJ0ZXIgYmFzaGluZy4uDQo+Pg0KPj5IZW5u aW5nLA0KPj4NCj4+SSdtIG5vdCBzdXJlICdjYXJyaWVyIEInIHdvdWxkIGluIHRoZSAiaW4tYmFu ZCBjYXNlIiBoYXZlIG5vIGluY2VudGl2ZSB0bw0KPj51c2UgYSAzcmQgcGFydHkgc2VydmljZS4g IEl0IG1pZ2h0IGJlIHRoYXQgdGhlIDNyZCBwYXJ0eSBzZXJ2aWNlIHByb3ZpZGVzDQo+PmFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gYW5kL29yIGlzIGNvbnNpZGVyZWQgbW9yZSB0cnVzdHdvcnRoeSB0 aGFuIHdob2V2ZXINCj4+cHJvdmlkZWQgdGhlIGluLWJhbmQgaW5mb3JtYXRpb24uICBXZSBjYW4g KGFuZCBJIGhvcGUgd2lsbCkgY2hhbmdlIHRoZQ0KPj5pbmNlbnRpdmVzLiAgSSB0aGluayBpdCB3 b3VsZCBiZSBhIHJlYXNvbmFibGUgb2JqZWN0aXZlIHRvIGNhcnJ5IHdoYXRldmVyDQo+PmNvbnRl bnQgaXMgZGVlbWVkICJuZWNlc3NhcnkiIHRvIHNlcnZlIHRoZSBwdWJsaWMsIGluLWJhbmQuICBJ ZiBwZW9wbGUNCj4+d2FudCB0byBvcGVyYXRlIGRhdGFiYXNlcyBmdWxsIG9mIGNhbGxpbmcgcGFy dHkncyBjYXQgcGljdHVyZXMsIGFuZA0KPj5DYXJyaWVyIEIgd2FudHMgdG8gcHJvdmlkZSB0aGlz IHRvIHRoZWlyIGN1c3RvbWVyIChvciBhbGxvdyB0aGVpcg0KPj5jdXN0b21lciB0byBvYnRhaW4g aXQgdGhlbXNlbHZlcywgZS5nLiwgcHJvdmlkZSB0aGVtIGEgbGluayB0byBpdCkgdGhhdCdzDQo+ PmFsbCBPSyB3aXRoIG1lLg0KPj4NCj4+SSBhZ3JlZSB3aXRoIHlvdSBhYm91dCB0aGUgaW1wb3J0 YW5jZSBvZiBiZWluZyBhYmxlIHRvIGtub3cNCj4+dW5hbWJpZ3VvdXNseSwgd2hvIGluc2VydGVk IHRoZSBpbmZvcm1hdGlvbi4NCj4+DQo+PlRpbQ0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Y25pdCBtYWlsaW5nIGxpc3QNCj4+Y25pdEBp ZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NuaXQNCj4N Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmNu aXQgbWFpbGluZyBsaXN0DQo+Y25pdEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY25pdA0KDQo= From nobody Mon Jun 29 19:28:17 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EA51B2F42 for ; Mon, 29 Jun 2015 19:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoQzqL-Sjha6 for ; Mon, 29 Jun 2015 19:28:15 -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 362891B2F3F for ; Mon, 29 Jun 2015 19:28:15 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Peterson, Jon" Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tADGHMBAAITkHRAAICivQADuTr0wACUe6gALCtpOA///oz+Q= Date: Tue, 30 Jun 2015 02:28:13 +0000 References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326E8D@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326EC8@FHDP1LUMXC7V31.us.one.verizon.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 02:28:17 -0000 I was wondering if it would work to have two STIR headers, with the second = binding the phone number to the display name (and other SIP headers, to pre= vent replay). Obviously, downstream validating parties have to have a reaso= n to trust the signing party, but that always seems to be the case when you= don't have the number signer as the implied originating carrier computing = the signature.=0A= =0A= ________________________________________=0A= From: Peterson, Jon [jon.peterson@neustar.biz]=0A= Sent: Monday, June 29, 2015 7:47 PM=0A= To: Richard Shockey; Henning Schulzrinne; Dwight, Timothy M (Tim)=0A= Cc: cnit@ietf.org=0A= Subject: Re: [cnit] CNIT Charter bashing..=0A= =0A= It's not clear to me that we need any STIR-like mechanisms to be in place= =0A= before embarking on CNIT. What I've basically written in to STIR is an=0A= extension field that CNIT could use to hook into the signature. All it=0A= would require is that CNIT create a specification (as currently written, a= =0A= Standards Track RFC) that designates what the field(s) that will be=0A= signed, and then the necessary procedures and so on.=0A= =0A= Fundamentally I agree that hooking CNIT into STIR will only provide part=0A= of a solution. There are going to be cases when the entity that originates= =0A= (or signs) SIP signaling is not going to be the right party to attest to=0A= the proper display name for a user.=0A= =0A= Architecturally, what I'd probably prefer is to think about this work as=0A= designing a small, but somewhat extensible block of information which=0A= someone could sign. Small enough that it could fit in a SIP message, and=0A= be signed there by hooking into the STIR extension field. But also=0A= something that could be carried by an external protocol for those cases=0A= when the STIR signer might not be the authority on the display name. Maybe= =0A= the STIR signer would fetch it via that external protocol, and then pass=0A= along the signature of the authority from whom they acquired it, in=0A= addition to signing it themselves. Or maybe the recipient would use the=0A= external protocol if there is no STIR hook. If we build a system with=0A= roughly those qualities, and focus more on the info block than on how it=0A= gets transported necessarily, I think we'll do some valuable work.=0A= =0A= Jon Peterson=0A= Neustar, Inc.=0A= =0A= On 6/15/15, 3:32 PM, "Richard Shockey" wrote:=0A= =0A= >=0A= >Tim Henning .. This is uniquely timely and important because the SIP Forum= =0A= >is at this moment attempting to revise its SIPConnect Recommendation for= =0A= >PBX / hosted to SSP interface where the data may be originated by the=0A= >enterprise and it needs to be treated in some way by the NNI. (hopefully= =0A= >maybe not stripped if its seen in the FROM or P-AI)=0A= >=0A= >Its a complication but not insurmountable. It clearly shows we need to=0A= >rethink the charter and look at some baby steps vs demanding that all the= =0A= >STIR like mechanisms be in place before there is progress.=0A= >=0A= >=0A= >=0A= >=8B=0A= >Richard Shockey=0A= >Shockey Consulting LLC=0A= >Chairman of the Board SIP Forum=0A= >www.shockey.us=0A= >www.sipforum.org=0A= >richardshockey.us=0A= >Skype-Linkedin-Facebook rshockey101=0A= >PSTN +1 703-593-2683=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >On 6/15/15, 6:11 PM, "Henning Schulzrinne" = =0A= >wrote:=0A= >=0A= >>Agreed that the terminating carrier can provide added value, e.g., by=0A= >>linking to other information. You could imagine mapping numbers to BBB=0A= >>information, or databases or registered charities, or Yelp... I am=0A= >>somewhat surprised that this isn't happening already more broadly.=0A= >>=0A= >>________________________________________=0A= >>From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]=0A= >>Sent: Sunday, June 14, 2015 1:58 PM=0A= >>To: Henning Schulzrinne=0A= >>Cc: cnit@ietf.org=0A= >>Subject: RE: [cnit] CNIT Charter bashing..=0A= >>=0A= >>Henning,=0A= >>=0A= >>I'm not sure 'carrier B' would in the "in-band case" have no incentive to= =0A= >>use a 3rd party service. It might be that the 3rd party service provides= =0A= >>additional information and/or is considered more trustworthy than whoever= =0A= >>provided the in-band information. We can (and I hope will) change the=0A= >>incentives. I think it would be a reasonable objective to carry whatever= =0A= >>content is deemed "necessary" to serve the public, in-band. If people=0A= >>want to operate databases full of calling party's cat pictures, and=0A= >>Carrier B wants to provide this to their customer (or allow their=0A= >>customer to obtain it themselves, e.g., provide them a link to it) that's= =0A= >>all OK with me.=0A= >>=0A= >>I agree with you about the importance of being able to know=0A= >>unambiguously, who inserted the information.=0A= >>=0A= >>Tim=0A= >>=0A= >>_______________________________________________=0A= >>cnit mailing list=0A= >>cnit@ietf.org=0A= >>https://www.ietf.org/mailman/listinfo/cnit=0A= >=0A= >=0A= >_______________________________________________=0A= >cnit mailing list=0A= >cnit@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= From nobody Mon Jun 29 21:45:35 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DDD1B30B8 for ; Mon, 29 Jun 2015 21:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRtqM7GmsIKB for ; Mon, 29 Jun 2015 21:45:32 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72341B30B3 for ; Mon, 29 Jun 2015 21:45:31 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t5U4ie25026449; Tue, 30 Jun 2015 00:45:30 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1vbe5r8bw0-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Jun 2015 00:45:30 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 30 Jun 2015 00:45:29 -0400 From: "Peterson, Jon" To: Henning Schulzrinne Thread-Topic: [cnit] CNIT Charter bashing.. Thread-Index: AQHQpF27KGEooroT50KUThK45F2vPZ2nvtOAgAAcbYCAAAFnAIABDhMAgAA9LQCAAAZIgIAAAREAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgIAANESAgAGXr4CAAP2pAIAAQ9wAgAHZCwCAAAXIgIAVoFeAgACiRID//7D7AA== Date: Tue, 30 Jun 2015 04:45:29 +0000 Message-ID: References: <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <557AE9E4.5030205@cs.tcd.ie> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326E8D@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30279326EC8@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.128.52] Content-Type: text/plain; charset="utf-8" Content-ID: <6098E5DB168D734899E5673193277568@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-30_01:2015-06-29,2015-06-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1506300085 Archived-At: Cc: "cnit@ietf.org" Subject: Re: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 04:45:34 -0000 DQpUaGlzIGlzIG1vcmUgb3IgbGVzcyBob3cgSSBpbWFnaW5lIGl0IGNvdWxkIHdvcmsuDQoNCk5v dCB0byBnZXQgYWhlYWQgb2YgYSBkcmFmdCBJIGhhdmVuJ3Qgc3VibWl0dGVkIHlldCwgYnV0IGJh c2ljYWxseSB0aGUNCnJldmlzZWQgcmZjNDQ3NGJpcyB0ZXh0IGNyZWF0ZXMgYW4gb3B0aW9uYWwg SWRlbnRpdHktRXh0ZW5zaW9uIGhlYWRlcg0Kd2hpY2ggYWxsb3dzIGZ1dHVyZSBzcGVjaWZpY2F0 aW9ucyB0byBkZWZpbmUgYSBuZXcgZmllbGQgb3Igc2V0IG9mIGZpZWxkcw0KdGhhdCBhIHNpZ25h dHVyZSB3b3VsZCBmYWxsIG92ZXIuIFRoZSBtYWluIElkZW50aXR5IHNpZ25hdHVyZSBhbHNvIGNv dmVycw0KdGhlIGNvbnRlbnRzIG9mIElkZW50aXR5LUV4dGVuc2lvbiwgd2hlbiBpdCBpcyBwcmVz ZW50LiBTbywgaWYgQ05JVCB3ZXJlDQp0byBkZWNpZGUgdG8ganVzdCB1c2UgdGhlIEZyb20gZGlz cGxheS1uYW1lLCBhIG5ldyBJZGVudGl0eS1FeHRlbnNpb24NCmhlYWRlciBzaWduYXR1cmUgb3Zl ciB0aGUgZGlzcGxheS1uYW1lIGFsb25lIGNvdWxkIGJlIGRlZmluZWQuIElmIENOSVQNCmRlZmlu ZXMgYSBuZXcgaGVhZGVyLCBsaWtlIGh5cG90aGV0aWNhbGx5IGEgQ05JVC1OYW1lIGhlYWRlciwg dGhlbiB0aGUNCmNvbnRlbnRzIG9mIHRoZSBJZGVudGl0eS1FeHRlbnNpb24gaGVhZGVyIGZpZWxk IGNvdWxkIGJlIGEgc2lnbmF0dXJlIG92ZXINCkNOSVQtTmFtZS4gVGhpcyBzZWVtZWQgbGlrZSB0 aGUgd2F5IHdlIGNvdWxkIGFjY29tbW9kYXRlIHRoZSBicm9hZGVzdCBzZXQNCm9mIGRlc2lnbiBj aG9pY2VzIGZvciBDTklULg0KDQpTbyBlZmZlY3RpdmVseSB0aGlzIG1lY2hhbmlzbSBzaG91bGQg YWxsb3cgYSBzZXBhcmF0ZSBoZWFkZXIgdGhhdCBiaW5kcw0KdGhlIHNpZ25hdHVyZSBvdmVyIHRo ZSBwaG9uZSBudW1iZXIgdG8gdGhlIHNpZ25hdHVyZSBpbiB0aGUNCklkZW50aXR5LUV4dGVuc2lv biBoZWFkZXIsIHdoaWNoIGluIHR1cm4gd291bGQgY292ZXIgdGhlIG5hbWUuIElmIGl0IHR1cm5z DQpvdXQgdGhhdCBhIGh5cG90aGV0aWNhbCBDTklULU5hbWUgaGVhZGVyIGNvbnRhaW5zIGl0cyBv d24gc2lnbmF0dXJlIGZyb20NCnRoZSBhdXRob3JpdHkgYXR0ZXN0aW5nIGZvciB0aGUgZGlzcGxh eSBuYW1lLCBzZXBhcmF0ZSBmcm9tIHRoZSByZmM0NDc0YmlzDQpzaWcsIHRoZW4gZWl0aGVyIHRo YXQgY291bGQgYmUgc2lnbmVkIHZpYSB0aGUgSWRlbnRpdHktRXh0ZW5zaW9uIGhlYWRlciBvcg0K bm90LiBUaGF0IGFsc28gY292ZXJzIGNhc2VzIHdoZXJlIHRoZSBvcmlnaW5hdG9yIG9mIGEgU0lQ IHJlcXVlc3QgaXNuJ3QNCnRoZSBhdXRob3JpdHkgZm9yIHRoZSBudW1iZXIgKGxpa2UsIGlmIHRo ZSByZXF1ZXN0IGVudGVycyB0aGUgU0lQIHdvcmxkDQp0aHJvdWdoIGEgUFNUTiBnYXRld2F5KS4N Cg0KSm9uIFBldGVyc29uDQpOZXVzdGFyLCBJbmMuDQoNCk9uIDYvMjkvMTUsIDc6MjggUE0sICJI ZW5uaW5nIFNjaHVsenJpbm5lIiA8SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292Pg0Kd3JvdGU6 DQoNCj5JIHdhcyB3b25kZXJpbmcgaWYgaXQgd291bGQgd29yayB0byBoYXZlIHR3byBTVElSIGhl YWRlcnMsIHdpdGggdGhlDQo+c2Vjb25kIGJpbmRpbmcgdGhlIHBob25lIG51bWJlciB0byB0aGUg ZGlzcGxheSBuYW1lIChhbmQgb3RoZXIgU0lQDQo+aGVhZGVycywgdG8gcHJldmVudCByZXBsYXkp LiBPYnZpb3VzbHksIGRvd25zdHJlYW0gdmFsaWRhdGluZyBwYXJ0aWVzDQo+aGF2ZSB0byBoYXZl IGEgcmVhc29uIHRvIHRydXN0IHRoZSBzaWduaW5nIHBhcnR5LCBidXQgdGhhdCBhbHdheXMgc2Vl bXMNCj50byBiZSB0aGUgY2FzZSB3aGVuIHlvdSBkb24ndCBoYXZlIHRoZSBudW1iZXIgc2lnbmVy IGFzIHRoZSBpbXBsaWVkDQo+b3JpZ2luYXRpbmcgY2FycmllciBjb21wdXRpbmcgdGhlIHNpZ25h dHVyZS4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+RnJv bTogUGV0ZXJzb24sIEpvbiBbam9uLnBldGVyc29uQG5ldXN0YXIuYml6XQ0KPlNlbnQ6IE1vbmRh eSwgSnVuZSAyOSwgMjAxNSA3OjQ3IFBNDQo+VG86IFJpY2hhcmQgU2hvY2tleTsgSGVubmluZyBT Y2h1bHpyaW5uZTsgRHdpZ2h0LCBUaW1vdGh5IE0gKFRpbSkNCj5DYzogY25pdEBpZXRmLm9yZw0K PlN1YmplY3Q6IFJlOiBbY25pdF0gQ05JVCBDaGFydGVyIGJhc2hpbmcuLg0KPg0KPkl0J3Mgbm90 IGNsZWFyIHRvIG1lIHRoYXQgd2UgbmVlZCBhbnkgU1RJUi1saWtlIG1lY2hhbmlzbXMgdG8gYmUg aW4gcGxhY2UNCj5iZWZvcmUgZW1iYXJraW5nIG9uIENOSVQuIFdoYXQgSSd2ZSBiYXNpY2FsbHkg d3JpdHRlbiBpbiB0byBTVElSIGlzIGFuDQo+ZXh0ZW5zaW9uIGZpZWxkIHRoYXQgQ05JVCBjb3Vs ZCB1c2UgdG8gaG9vayBpbnRvIHRoZSBzaWduYXR1cmUuIEFsbCBpdA0KPndvdWxkIHJlcXVpcmUg aXMgdGhhdCBDTklUIGNyZWF0ZSBhIHNwZWNpZmljYXRpb24gKGFzIGN1cnJlbnRseSB3cml0dGVu LCBhDQo+U3RhbmRhcmRzIFRyYWNrIFJGQykgdGhhdCBkZXNpZ25hdGVzIHdoYXQgdGhlIGZpZWxk KHMpIHRoYXQgd2lsbCBiZQ0KPnNpZ25lZCwgYW5kIHRoZW4gdGhlIG5lY2Vzc2FyeSBwcm9jZWR1 cmVzIGFuZCBzbyBvbi4NCj4NCj5GdW5kYW1lbnRhbGx5IEkgYWdyZWUgdGhhdCBob29raW5nIENO SVQgaW50byBTVElSIHdpbGwgb25seSBwcm92aWRlIHBhcnQNCj5vZiBhIHNvbHV0aW9uLiBUaGVy ZSBhcmUgZ29pbmcgdG8gYmUgY2FzZXMgd2hlbiB0aGUgZW50aXR5IHRoYXQgb3JpZ2luYXRlcw0K PihvciBzaWducykgU0lQIHNpZ25hbGluZyBpcyBub3QgZ29pbmcgdG8gYmUgdGhlIHJpZ2h0IHBh cnR5IHRvIGF0dGVzdCB0bw0KPnRoZSBwcm9wZXIgZGlzcGxheSBuYW1lIGZvciBhIHVzZXIuDQo+ DQo+QXJjaGl0ZWN0dXJhbGx5LCB3aGF0IEknZCBwcm9iYWJseSBwcmVmZXIgaXMgdG8gdGhpbmsg YWJvdXQgdGhpcyB3b3JrIGFzDQo+ZGVzaWduaW5nIGEgc21hbGwsIGJ1dCBzb21ld2hhdCBleHRl bnNpYmxlIGJsb2NrIG9mIGluZm9ybWF0aW9uIHdoaWNoDQo+c29tZW9uZSBjb3VsZCBzaWduLiBT bWFsbCBlbm91Z2ggdGhhdCBpdCBjb3VsZCBmaXQgaW4gYSBTSVAgbWVzc2FnZSwgYW5kDQo+YmUg c2lnbmVkIHRoZXJlIGJ5IGhvb2tpbmcgaW50byB0aGUgU1RJUiBleHRlbnNpb24gZmllbGQuIEJ1 dCBhbHNvDQo+c29tZXRoaW5nIHRoYXQgY291bGQgYmUgY2FycmllZCBieSBhbiBleHRlcm5hbCBw cm90b2NvbCBmb3IgdGhvc2UgY2FzZXMNCj53aGVuIHRoZSBTVElSIHNpZ25lciBtaWdodCBub3Qg YmUgdGhlIGF1dGhvcml0eSBvbiB0aGUgZGlzcGxheSBuYW1lLiBNYXliZQ0KPnRoZSBTVElSIHNp Z25lciB3b3VsZCBmZXRjaCBpdCB2aWEgdGhhdCBleHRlcm5hbCBwcm90b2NvbCwgYW5kIHRoZW4g cGFzcw0KPmFsb25nIHRoZSBzaWduYXR1cmUgb2YgdGhlIGF1dGhvcml0eSBmcm9tIHdob20gdGhl eSBhY3F1aXJlZCBpdCwgaW4NCj5hZGRpdGlvbiB0byBzaWduaW5nIGl0IHRoZW1zZWx2ZXMuIE9y IG1heWJlIHRoZSByZWNpcGllbnQgd291bGQgdXNlIHRoZQ0KPmV4dGVybmFsIHByb3RvY29sIGlm IHRoZXJlIGlzIG5vIFNUSVIgaG9vay4gSWYgd2UgYnVpbGQgYSBzeXN0ZW0gd2l0aA0KPnJvdWdo bHkgdGhvc2UgcXVhbGl0aWVzLCBhbmQgZm9jdXMgbW9yZSBvbiB0aGUgaW5mbyBibG9jayB0aGFu IG9uIGhvdyBpdA0KPmdldHMgdHJhbnNwb3J0ZWQgbmVjZXNzYXJpbHksIEkgdGhpbmsgd2UnbGwg ZG8gc29tZSB2YWx1YWJsZSB3b3JrLg0KPg0KPkpvbiBQZXRlcnNvbg0KPk5ldXN0YXIsIEluYy4N Cj4NCj5PbiA2LzE1LzE1LCAzOjMyIFBNLCAiUmljaGFyZCBTaG9ja2V5IiA8cmljaGFyZEBzaG9j a2V5LnVzPiB3cm90ZToNCj4NCj4+DQo+PlRpbSBIZW5uaW5nIC4uIFRoaXMgaXMgdW5pcXVlbHkg dGltZWx5IGFuZCBpbXBvcnRhbnQgYmVjYXVzZSB0aGUgU0lQDQo+PkZvcnVtDQo+PmlzIGF0IHRo aXMgbW9tZW50IGF0dGVtcHRpbmcgdG8gcmV2aXNlIGl0cyBTSVBDb25uZWN0IFJlY29tbWVuZGF0 aW9uIGZvcg0KPj5QQlggLyBob3N0ZWQgdG8gU1NQIGludGVyZmFjZSB3aGVyZSB0aGUgZGF0YSBt YXkgYmUgb3JpZ2luYXRlZCBieSB0aGUNCj4+ZW50ZXJwcmlzZSBhbmQgaXQgbmVlZHMgdG8gYmUg dHJlYXRlZCBpbiBzb21lIHdheSBieSB0aGUgTk5JLiAoaG9wZWZ1bGx5DQo+Pm1heWJlIG5vdCBz dHJpcHBlZCBpZiBpdHMgc2VlbiBpbiB0aGUgRlJPTSBvciBQLUFJKQ0KPj4NCj4+SXRzIGEgY29t cGxpY2F0aW9uIGJ1dCBub3QgaW5zdXJtb3VudGFibGUuIEl0IGNsZWFybHkgc2hvd3Mgd2UgbmVl ZCB0bw0KPj5yZXRoaW5rIHRoZSBjaGFydGVyIGFuZCBsb29rIGF0IHNvbWUgYmFieSBzdGVwcyB2 cyBkZW1hbmRpbmcgdGhhdCBhbGwgdGhlDQo+PlNUSVIgbGlrZSBtZWNoYW5pc21zIGJlIGluIHBs YWNlIGJlZm9yZSB0aGVyZSBpcyBwcm9ncmVzcy4NCj4+DQo+Pg0KPj4NCj4+4oC5DQo+PlJpY2hh cmQgU2hvY2tleQ0KPj5TaG9ja2V5IENvbnN1bHRpbmcgTExDDQo+PkNoYWlybWFuIG9mIHRoZSBC b2FyZCBTSVAgRm9ydW0NCj4+d3d3LnNob2NrZXkudXMNCj4+d3d3LnNpcGZvcnVtLm9yZw0KPj5y aWNoYXJkPGF0PnNob2NrZXkudXMNCj4+U2t5cGUtTGlua2VkaW4tRmFjZWJvb2sgcnNob2NrZXkx MDENCj4+UFNUTiArMSA3MDMtNTkzLTI2ODMNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj5PbiA2LzE1 LzE1LCA2OjExIFBNLCAiSGVubmluZyBTY2h1bHpyaW5uZSIgPEhlbm5pbmcuU2NodWx6cmlubmVA ZmNjLmdvdj4NCj4+d3JvdGU6DQo+Pg0KPj4+QWdyZWVkIHRoYXQgdGhlIHRlcm1pbmF0aW5nIGNh cnJpZXIgY2FuIHByb3ZpZGUgYWRkZWQgdmFsdWUsIGUuZy4sIGJ5DQo+Pj5saW5raW5nIHRvIG90 aGVyIGluZm9ybWF0aW9uLiBZb3UgY291bGQgaW1hZ2luZSBtYXBwaW5nIG51bWJlcnMgdG8gQkJC DQo+Pj5pbmZvcm1hdGlvbiwgb3IgZGF0YWJhc2VzIG9yIHJlZ2lzdGVyZWQgY2hhcml0aWVzLCBv ciBZZWxwLi4uIEkgYW0NCj4+PnNvbWV3aGF0IHN1cnByaXNlZCB0aGF0IHRoaXMgaXNuJ3QgaGFw cGVuaW5nIGFscmVhZHkgbW9yZSBicm9hZGx5Lg0KPj4+DQo+Pj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj5Gcm9tOiBEd2lnaHQsIFRpbW90aHkgTSAoVGltKSBb dGltb3RoeS5kd2lnaHRAdmVyaXpvbi5jb21dDQo+Pj5TZW50OiBTdW5kYXksIEp1bmUgMTQsIDIw MTUgMTo1OCBQTQ0KPj4+VG86IEhlbm5pbmcgU2NodWx6cmlubmUNCj4+PkNjOiBjbml0QGlldGYu b3JnDQo+Pj5TdWJqZWN0OiBSRTogW2NuaXRdIENOSVQgQ2hhcnRlciBiYXNoaW5nLi4NCj4+Pg0K Pj4+SGVubmluZywNCj4+Pg0KPj4+SSdtIG5vdCBzdXJlICdjYXJyaWVyIEInIHdvdWxkIGluIHRo ZSAiaW4tYmFuZCBjYXNlIiBoYXZlIG5vIGluY2VudGl2ZQ0KPj4+dG8NCj4+PnVzZSBhIDNyZCBw YXJ0eSBzZXJ2aWNlLiAgSXQgbWlnaHQgYmUgdGhhdCB0aGUgM3JkIHBhcnR5IHNlcnZpY2UNCj4+ PnByb3ZpZGVzDQo+Pj5hZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFuZC9vciBpcyBjb25zaWRlcmVk IG1vcmUgdHJ1c3R3b3J0aHkgdGhhbg0KPj4+d2hvZXZlcg0KPj4+cHJvdmlkZWQgdGhlIGluLWJh bmQgaW5mb3JtYXRpb24uICBXZSBjYW4gKGFuZCBJIGhvcGUgd2lsbCkgY2hhbmdlIHRoZQ0KPj4+ aW5jZW50aXZlcy4gIEkgdGhpbmsgaXQgd291bGQgYmUgYSByZWFzb25hYmxlIG9iamVjdGl2ZSB0 byBjYXJyeQ0KPj4+d2hhdGV2ZXINCj4+PmNvbnRlbnQgaXMgZGVlbWVkICJuZWNlc3NhcnkiIHRv IHNlcnZlIHRoZSBwdWJsaWMsIGluLWJhbmQuICBJZiBwZW9wbGUNCj4+PndhbnQgdG8gb3BlcmF0 ZSBkYXRhYmFzZXMgZnVsbCBvZiBjYWxsaW5nIHBhcnR5J3MgY2F0IHBpY3R1cmVzLCBhbmQNCj4+ PkNhcnJpZXIgQiB3YW50cyB0byBwcm92aWRlIHRoaXMgdG8gdGhlaXIgY3VzdG9tZXIgKG9yIGFs bG93IHRoZWlyDQo+Pj5jdXN0b21lciB0byBvYnRhaW4gaXQgdGhlbXNlbHZlcywgZS5nLiwgcHJv dmlkZSB0aGVtIGEgbGluayB0byBpdCkNCj4+PnRoYXQncw0KPj4+YWxsIE9LIHdpdGggbWUuDQo+ Pj4NCj4+PkkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgdGhlIGltcG9ydGFuY2Ugb2YgYmVpbmcgYWJs ZSB0byBrbm93DQo+Pj51bmFtYmlndW91c2x5LCB3aG8gaW5zZXJ0ZWQgdGhlIGluZm9ybWF0aW9u Lg0KPj4+DQo+Pj5UaW0NCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PmNuaXQgbWFpbGluZyBsaXN0DQo+Pj5jbml0QGlldGYub3JnDQo+ Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NuaXQNCj4+DQo+Pg0KPj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5jbml0IG1h aWxpbmcgbGlzdA0KPj5jbml0QGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY25pdA0KPg0KDQo=