Re: [cnit] CNIT Charter bashing..

Richard Shockey <richard@shockey.us> Sun, 14 June 2015 14:41 UTC

Return-Path: <richard@shockey.us>
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 <cnit@ietfa.amsl.com>; 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 <cnit@ietfa.amsl.com>; 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 <cnit@ietf.org>; 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 <richard@shockey.us>) 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 <richard@shockey.us>
To: "Dwight, Timothy M (Tim)" <timothy.dwight@verizon.com>, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>, "cnit@ietf.org" <cnit@ietf.org>
Message-ID: <D1A30149.27095%richard@shockey.us>
Thread-Topic: [cnit] CNIT Charter bashing..
References: <D19F23AD.26CEA%richard@shockey.us> <E42CCDDA6722744CB241677169E8365603614617@MISOUT7MSGUSRDB.ITServices.sbc.com> <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <E6A16181E5FD2F46B962315BB05962D07D354C94@fcc.gov> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <D1A05A04.26E84%richard@shockey.us> <E6A16181E5FD2F46B962315BB05962D07D355543@fcc.gov> <557AE9E4.5030205@cs.tcd.ie> <D1A0761F.26EE1%richard@shockey.us> <2B0F677F0B95454297753F58D4A07FA30279326B59@FHDP1LUMXC7V31.us.one.verizon.com> <E6A16181E5FD2F46B962315BB05962D07D355940@fcc.gov> <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: <http://mailarchive.ietf.org/arch/msg/cnit/Y8rBC1kZW8EpI46tl-5ajb_Y7Rk>
Subject: Re: [cnit] CNIT Charter bashing..
X-BeenThere: cnit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Calling Name Identity Trust discussion list <cnit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cnit>, <mailto:cnit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cnit/>
List-Post: <mailto:cnit@ietf.org>
List-Help: <mailto:cnit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cnit>, <mailto:cnit-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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)"
<timothy.dwight@verizon.com> 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¹s 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.
   
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¹t
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
³paper trail² nor subject to fat thumb ³send all² 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" <stephen.farrell@cs.tcd.ie> wrote:
>
>>
>>
>>On 12/06/15 15:13, Henning Schulzrinne wrote:
>>> In almost all cases of interest, the calling party *wants* to
>>> disclose accurate information to the called party, so the privacy
>>> issues don't seem to arise. They would only arise if there was forced
>>> disclosure; I don't think anybody is proposing that.
>>
>>Privacy issues could also arise if a middlebox could now see sensitive
>>information that it previously could not see. I think that is
>>independent of whether disclosure is desired by either of the
>>endpoints.
>>
>>S.
>>
>>_______________________________________________
>>cnit mailing list
>>cnit@ietf.org
>>https://www.ietf.org/mailman/listinfo/cnit
>
>
>_______________________________________________
>cnit mailing list
>cnit@ietf.org
>https://www.ietf.org/mailman/listinfo/cnit
>
>
>_______________________________________________
>cnit mailing list
>cnit@ietf.org
>https://www.ietf.org/mailman/listinfo/cnit
>
>_______________________________________________
>cnit mailing list
>cnit@ietf.org
>https://www.ietf.org/mailman/listinfo/cnit