From dhc@dcrocker.net Thu Aug 1 00:08:09 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4197021F9DBB for ; Thu, 1 Aug 2013 00:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eWG2PsMJ6EL for ; Thu, 1 Aug 2013 00:08:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E64A21F9DA5 for ; Thu, 1 Aug 2013 00:07:15 -0700 (PDT) Received: from [192.168.1.203] (e178125099.adsl.alicedsl.de [85.178.125.99]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r71772a9032254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 00:07:08 -0700 Message-ID: <51FA090B.5000009@dcrocker.net> Date: Thu, 01 Aug 2013 09:06:51 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Kent References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> In-Reply-To: <51FA0753.6020600@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 01 Aug 2013 00:07:11 -0700 (PDT) Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:08:09 -0000 On 8/1/2013 8:59 AM, Stephen Kent wrote: > Dave, > > I refer you to the BGPSEC threat doc > (draft-ietf-sidr-bgpsec-threats-05), which is now > in the hands of the RTG ADs, as an example of what I have in mind. It > addresses a > fairly complex, global system, so I would not expect an analogous doc > for STIR > to be any longer. ack. tnx for the reference. looks quite helpful. this does suggest that it would be helpful for the secdir to produce some sort of template to guide us plebes in our efforts to pretend we can be competent in these exercises. it might also increase the consistency of what different secdir and sec AD folk require from these exercises... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Thu Aug 1 00:12:04 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA1821F9A25 for ; Thu, 1 Aug 2013 00:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAZ8+q6grB-4 for ; Thu, 1 Aug 2013 00:11:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9807A21F9635 for ; Thu, 1 Aug 2013 00:11:56 -0700 (PDT) Received: from [192.168.1.203] (e178125099.adsl.alicedsl.de [85.178.125.99]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r717BfYx032370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 00:11:48 -0700 Message-ID: <51FA0A29.5090901@dcrocker.net> Date: Thu, 01 Aug 2013 09:11:37 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 01 Aug 2013 00:11:49 -0700 (PDT) Cc: IETF STIR Mail List , David Hancock Subject: Re: [stir] DNS for STIR: draft-kaplan-stir-cider-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:12:04 -0000 On 7/30/2013 9:29 PM, Hadriel Kaplan wrote: > in such a case there might be two or more public keys in the DNS for the same E.164 phone number, but under different "key index" names and thus separate TXT RR entries. To emphasize these design features a bit more: Key management: The "index" (what DKIM calls "selector") is an administrative "adjective" to the registered, visible value (in this case the telephone number.) It's added to the value, so that there can be multiple keys associated with a single value. The value is what is seen and what is used for making reputation assessments, but the DNS lookup string has the index added to it, to permit accessing different DNS records associated with the value. Having multiple keys makes it convenient to roll over to new ones while still supporting old ones, if there is a desire to limit the window of exposure for individual keys. It also permits multiple, independent signers for the same value (number), with each being given permission that can be independently controlled by whoever has the 'master' authority over key management. Individual permission can be delegated and the permission can then be terminated at any time, by simply removing that index's DNS entry. This removal takes effect within DNS cache TTL time and obviates the need for a distinct certificate revocation mechanism. Administrative choice: As Hadriel notes, there are multiple ways to organize basic authority over key management, specific authority to upload individual public keys and specific authority to sign with the individual private keys. This group has already debated some authority choices a bit and I'm sure there will be more. The CIDER approach might or might not permit /all/ variations of administrative choice, but it certainly permits a number of them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From rlb@ipv.sx Thu Aug 1 00:26:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDB221F918C for ; Thu, 1 Aug 2013 00:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49dJWyYzb8nK for ; Thu, 1 Aug 2013 00:26:35 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 571AB21F8A85 for ; Thu, 1 Aug 2013 00:26:35 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so3632886oag.14 for ; Thu, 01 Aug 2013 00:26:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4FbMR3m/RZLCNH/6Gw8IwLtPP6WjvHy8VEEGfsA2iB8=; b=S/sMDzw4puMVR4kr/hvkH38vAPm0Q0XvrzMiRV5AsNr3dWrG0F8/gylYghtp4TOcz4 aK+I/MuS1hFhsQbQBIlCH/pu9smxu04PIdn6QPH96vVHi6lUd82q9KHkTOMdtIRP511X oBmICOldhX9eD0M8WIBWrmkdJCkoakR7lHKGdJ131OqtCTbuqHfg4HIcAZ91srObIIOk XCzUhV2ecid+hOaXmCN2ob0xBpdmgOE8DmuboGamZ+Enx3pw57uLnOCyGr15FjzHaVVX gbVGAFLw+STMZwtPYAKHE6V4yK+aI3HWtqPJHbmzRPtA7Ow33r7rdx+D6X+k9SugT+RQ 6zUQ== MIME-Version: 1.0 X-Received: by 10.182.27.74 with SMTP id r10mr125905obg.63.1375341994819; Thu, 01 Aug 2013 00:26:34 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Thu, 1 Aug 2013 00:26:34 -0700 (PDT) X-Originating-IP: [130.129.19.90] In-Reply-To: <51F9F08C.3050700@dcrocker.net> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> <51F9F08C.3050700@dcrocker.net> Date: Thu, 1 Aug 2013 09:26:34 +0200 Message-ID: From: Richard Barnes To: Dave Crocker Content-Type: multipart/alternative; boundary=089e01184b2e0be33504e2ddc39a X-Gm-Message-State: ALoCoQkaSyBhL3beB3lsBaOjyaaRwwl5nHKvpm9EK/vztiRkpU7RaHVYdZslUK0IoB1+N0sxd52G Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:26:41 -0000 --089e01184b2e0be33504e2ddc39a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 1, 2013 at 7:22 AM, Dave Crocker wrote: > On 8/1/2013 12:25 AM, Richard Barnes wrote: > >> (In any event, I would encourage WG participants to keep in mind that >> there will likely substantial overlap between the two solutions. >> They both require a credential infrastructure and some sort of >> authenticated object that attests to the validity of a call. They >> might only really differ in how the authenticated object is delivered >> from originator to verifier. So we might find that some of the first >> things that are delivered are common to both solutions.) >> > > > > Richard, > > The above text is, of course, an entirely reasonable line of thinking. It > might even be correct, and for some approaches most certainly is. > > For others it isn't at all correct. > > The project management problem with what you've put forward is that any > meaningful version of "keeping out-of-band in mind" while working on > in-band effectively requires working on in-band and out-of-band > simultaneously. > > That's fundamentally different from working with complete focus on in-band > and only afterwards moving towards out-of-band. > > At every turn in considering choices for in-band, the implication of your > statement is that people will be raising concerns for application to > out-of-band. That essentially requires working out the details of > out-of-band simultaneously with in-band. > > This is quite contrary to what is usually meant in a charter about working > on one thing and /then/ on another. > > A charter is supposed to help reconcile these sorts of potential sources > of focus-confusion, rather than make them fuzzier. That's why I didn't propose putting it in the charter :) Obviously, we will try to clarify this in the charter. --Richard > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --089e01184b2e0be33504e2ddc39a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 1, 2013 at 7:22 AM, Dave Crocker <dhc@dcrocker= .net> wrote:
On 8/1/2013 12:25 AM, Rich= ard Barnes wrote:
(In any event, I would encourage WG participants to keep in mind that
there will likely substantial overlap between the two solutions.
They both require a credential infrastructure and some sort of
authenticated object that attests to the validity of a call. =A0They
might only really differ in how the authenticated object is delivered
from originator to verifier. =A0So we might find that some of the first
things that are delivered are common to both solutions.)



Richard,

The above text is, of course, an entirely reasonable line of thinking. It m= ight even be correct, and for some approaches most certainly is.

For others it isn't at all correct.

The project management problem with what you've put forward is that any= meaningful version of "keeping out-of-band in mind" while workin= g on in-band effectively requires working on in-band and out-of-band simult= aneously.

That's fundamentally different from working with complete focus on in-b= and and only afterwards moving towards out-of-band.

At every turn in considering choices for in-band, the implication of your s= tatement is that people will be raising concerns for application to out-of-= band. =A0That essentially requires working out the details of out-of-band s= imultaneously with in-band.

This is quite contrary to what is usually meant in a charter about working = on one thing and /then/ on another.

A charter is supposed to help reconcile these sorts of potential sources of= focus-confusion, rather than make them fuzzier.

That's why I didn't propose putting it in the charter :) =A0O= bviously, we will try to clarify this in the charter.

--Richard

=A0


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--089e01184b2e0be33504e2ddc39a-- From dhc@dcrocker.net Thu Aug 1 00:57:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB9721F9E4F for ; Thu, 1 Aug 2013 00:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihYxGvM9hKxB for ; Thu, 1 Aug 2013 00:57:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8215721F9E3F for ; Thu, 1 Aug 2013 00:57:13 -0700 (PDT) Received: from [192.168.1.203] (e178125099.adsl.alicedsl.de [85.178.125.99]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r717v28v000591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 00:57:09 -0700 Message-ID: <51FA14C9.6030903@dcrocker.net> Date: Thu, 01 Aug 2013 09:56:57 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Richard Barnes References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> <51F9F08C.3050700@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 01 Aug 2013 00:57:13 -0700 (PDT) Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:57:24 -0000 On 8/1/2013 9:26 AM, Richard Barnes wrote: > > That's why I didn't propose putting it in the charter :) Obviously, we > will try to clarify this in the charter. Color me even more confused than usual (and that's going some.) Advice from the cognizant AD about what technical issues to "consider" when working is usually treated as definitive direction, absent an overriding appeal (which isn't ever requested, nevermind sustained.) Perhaps you could respond to the substance of the concern I raised in my previous note? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From philippe.fouquart@orange.com Thu Aug 1 01:01:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDB621F9E6A for ; Thu, 1 Aug 2013 01:01:02 -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=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORdHQGkIzK1J for ; Thu, 1 Aug 2013 01:00:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 32ACB21F9B90 for ; Thu, 1 Aug 2013 01:00:54 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id EA229325223; Thu, 1 Aug 2013 10:00:52 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id CBAB84C07D; Thu, 1 Aug 2013 10:00:52 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 1 Aug 2013 10:00:52 +0200 From: To: Richard Shockey , 'Stephen Kent' , "'IETF STIR Mail List'" Thread-Topic: [stir] Moving from BOF to Charter Thread-Index: AQHOjfnriuCUt70jnUaMDMCvpNmmApl+x2+AgAAT1ICAARZDIA== Date: Thu, 1 Aug 2013 08:00:52 +0000 Message-ID: <29631_1375344052_51FA15B4_29631_481_1_B5939C6860701C49AA39C5DA5189448B0B7021@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> In-Reply-To: <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:01:03 -0000 Richard, Re you second point, you may want to have a look at the report that the Eur= opean NRA working group (ECC) on numbering produced on "Increasing Trust in= Calling Line Identification and Originating Identification" a few years ag= o but is still relevant. You'll find it at http://www.erodocdb.dk/docs/doc9= 8/official/pdf/ECCRep133.pdf.=20=20 As several interventions noted on Tuesday, including one from a European NR= A, it isn't specific to +1. But I think those jurisdictions address the iss= ue in the wider context of CLI trust, which broadly speaking falls into 3 c= ategories in Europe and probably elsewhere=20 a) The national robotcalling/vishing/swatting of the current charter=20 b) What Henning referred to as "cross-border" and "out of scope" in his pre= sentation (also referred to "numbering misuse" elsewhere)=20=20 c) Questionable commercial CLI practices by the legitimate number assignee = such as using premium rate numbers to generate return calls, for which a ce= rtified CLI won't help.=20 Some countries have developed BCPs to tackle those recently.=20 Slightly off-topic for a charter discussion, but I hope this helps. (unless= you wanted to add something to this end in the preamble)=20 Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ric= hard Shockey Sent: Wednesday, July 31, 2013 6:38 PM To: 'Stephen Kent'; 'IETF STIR Mail List' Subject: Re: [stir] Moving from BOF to Charter I agree though as Lucy Lynch pointed out in calling out attention to the privacy problem there may be an interesting dimension to this. When does the right to privacy trump the right to be anonymous? We are confronted with a situation where a genuine perceived need for anonymous communications identity for some has become a shield for criminal behavior.=20=20 The other issue maybe ISOC can help us with this problem is we still don't have an idea of the scope of the problem beyond North America. Other jurisdictions handle this differently and this is a perfect opportunity to encourage national regulators to engage with the IETF/ISOC in investigating these problems. I would argue that what we are seeing in North America is the "Canary in the Coal Mine".=20=20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, July 31, 2013 11:27 AM To: stir@ietf.org Subject: Re: [stir] Moving from BOF to Charter Russ, As I mentioned at the mic, I'd like to see both a threat model and a privacy analysis as deliverables early in this process. I also think we need to have a discussion about the size of the population of calling parties who will have credentials, and the size of the verifiers in the system. This seemed to be the source of some disagreement during the BoF, and some proposals that might work well for small values of either (or both) of these parameters might not work well for very large values of these parameters. The texts says: As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, Should the "authorization" be "authentication" above. I agree with the use of "authorized" in the latter part of the sentence. later, the text says: After completing the in-band mechanism, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authorization mechanism. Did you mean authorization or authentication here? Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ 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 gordon.lennox.13@gmail.com Thu Aug 1 01:10:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C74E21F9E00 for ; Thu, 1 Aug 2013 01:10:40 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eqWaf3b7lDl for ; Thu, 1 Aug 2013 01:10:39 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BCC3421F9BB6 for ; Thu, 1 Aug 2013 01:10:37 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so549639pbb.20 for ; Thu, 01 Aug 2013 01:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=65KHxik+QJhRIFRgAIT49cvUpjHCdO5RO3kMez/B6ZY=; b=rCYGVTrkcp7Q7KZXesEoyoI+03fBCOMx2sWrHyVYHHjDbM8i3ExwY2TswIe6TZGWTj 2YkgYk8KS6C6MgOLYZFtuu/lNwa8cpnUNdhgD6LBvfWGOHOcrxcXKXb+doJVNiOUILee PbGKhTAbzd8SLCY99zhK7PcCiXJ/6Mv9c9rlmszHHbqhNKFDGYomGM8lh665AAsxpR4l JFpog+6mXAahqAY8VLWQRHGlh86v1rEQQoPwRJ5E4awiXqCc+Hi6LeR7x4vVvZoRHh4I 5EEbuLPRzQj4inRqd6OAuIckobY2eTxXRltLCQn65sfoQ0p90vkTf+zyvzrqq72NT41S Uk2Q== X-Received: by 10.66.102.70 with SMTP id fm6mr2596929pab.57.1375344629399; Thu, 01 Aug 2013 01:10:29 -0700 (PDT) Received: from dhcp-174b.meeting.ietf.org (dhcp-174b.meeting.ietf.org. [130.129.23.75]) by mx.google.com with ESMTPSA id vu5sm2528112pab.10.2013.08.01.01.10.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 01:10:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gordon Lennox In-Reply-To: <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> Date: Thu, 1 Aug 2013 10:10:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58E52A04-537D-4DC4-8AD1-892185C0993F@gmail.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> To: Richard Shockey , IETF STIR Mail List X-Mailer: Apple Mail (2.1508) Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:10:40 -0000 On 31 Jul, 2013, at 18:38, Richard Shockey wrote: > I agree though as Lucy Lynch pointed out in calling out attention to = the > privacy problem there may be an interesting dimension to this. When = does the > right to privacy trump the right to be anonymous? We are confronted = with a > situation where a genuine perceived need for anonymous communications > identity for some has become a shield for criminal behavior. The Council of Europe is an international organisation promoting = co-operation between all countries of Europe in the areas of legal = standards, human rights, democratic development, the rule of law and = cultural co-operation. It is an entirely separate body from the European = Union (EU). Nearly all European countries are in the CoE including = Russia. But the US and Canada are also involved. Certain CoE conventions = have been opened to signature by non-members. Canada, Japan, South = Africa and the United States all signed the CoE Cybercrime Convention, = for example. About ten years ago the CoE Committee of Ministers adopted a Declaration = on freedom of communication on the Internet. That included: "Principle 7: Anonymity In order to ensure protection against online surveillance and to enhance = the free expression of information and ideas, member states should = respect the will of users of the Internet not to disclose their = identity. This does not prevent member states from taking measures and = co-operating in order to trace those responsible for criminal acts, in = accordance with national law, the Convention for the Protection of Human = Rights and Fundamental Freedoms and other international agreements in = the fields of justice and the police." I am sure there is more from the CoE on this. Gordon From richard@shockey.us Thu Aug 1 01:29:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C15C21F9DCB for ; Thu, 1 Aug 2013 01:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xD9ph1LN-rJ for ; Thu, 1 Aug 2013 01:29:53 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 291E921F9DBD for ; Thu, 1 Aug 2013 01:29:28 -0700 (PDT) Received: (qmail 26715 invoked by uid 0); 1 Aug 2013 08:29:23 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 1 Aug 2013 08:29:23 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=pfJSO/gtnP1K4TiIdBx+kXktxDVZNDVS3yMm91xYnlQ=; b=l0YaEqCXduNewqdIQsZuxHT5RkRfFcL3Int90WI3DuewAsyt9eZssBIEOwzGIsYfd6Vup5wXCxWimDGbUTTDAIAQzVhjI9W9snbsnxxYFXvX/sZP5a3aKI5Ac/UUtN45; Received: from [46.189.28.45] (port=63281 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4oGA-00027D-GN for stir@ietf.org; Thu, 01 Aug 2013 02:29:22 -0600 From: "Richard Shockey" To: "'IETF STIR Mail List'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> <29631_1375344052_51FA15B4_29631_481_1_B5939C6860701C49AA39C5DA5189448B0B7021@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <29631_1375344052_51FA15B4_29631_481_1_B5939C6860701C49AA39C5DA5189448B0B7021@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 1 Aug 2013 04:29:17 -0400 Message-ID: <007301ce8e91$396dc3a0$ac494ae0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAS+naHgCfFSlrZh9PJCA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 46.189.28.45 authed with richard@shockey.us} Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:29:58 -0000 Many thanks to you and Gordon for the interesting pointers. Though our focus is unquestionably technical, it certainly helps to understand the problem in context. -----Original Message----- From: philippe.fouquart@orange.com [mailto:philippe.fouquart@orange.com] Sent: Thursday, August 01, 2013 4:01 AM To: Richard Shockey; 'Stephen Kent'; 'IETF STIR Mail List' Subject: RE: [stir] Moving from BOF to Charter Richard, Re you second point, you may want to have a look at the report that the European NRA working group (ECC) on numbering produced on "Increasing Trust in Calling Line Identification and Originating Identification" a few years ago but is still relevant. You'll find it at http://www.erodocdb.dk/docs/doc98/official/pdf/ECCRep133.pdf. As several interventions noted on Tuesday, including one from a European NRA, it isn't specific to +1. But I think those jurisdictions address the issue in the wider context of CLI trust, which broadly speaking falls into 3 categories in Europe and probably elsewhere a) The national robotcalling/vishing/swatting of the current charter b) What Henning referred to as "cross-border" and "out of scope" in his presentation (also referred to "numbering misuse" elsewhere) c) Questionable commercial CLI practices by the legitimate number assignee such as using premium rate numbers to generate return calls, for which a certified CLI won't help. Some countries have developed BCPs to tackle those recently. Slightly off-topic for a charter discussion, but I hope this helps. (unless you wanted to add something to this end in the preamble) Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, July 31, 2013 6:38 PM To: 'Stephen Kent'; 'IETF STIR Mail List' Subject: Re: [stir] Moving from BOF to Charter I agree though as Lucy Lynch pointed out in calling out attention to the privacy problem there may be an interesting dimension to this. When does the right to privacy trump the right to be anonymous? We are confronted with a situation where a genuine perceived need for anonymous communications identity for some has become a shield for criminal behavior. The other issue maybe ISOC can help us with this problem is we still don't have an idea of the scope of the problem beyond North America. Other jurisdictions handle this differently and this is a perfect opportunity to encourage national regulators to engage with the IETF/ISOC in investigating these problems. I would argue that what we are seeing in North America is the "Canary in the Coal Mine". -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, July 31, 2013 11:27 AM To: stir@ietf.org Subject: Re: [stir] Moving from BOF to Charter Russ, As I mentioned at the mic, I'd like to see both a threat model and a privacy analysis as deliverables early in this process. I also think we need to have a discussion about the size of the population of calling parties who will have credentials, and the size of the verifiers in the system. This seemed to be the source of some disagreement during the BoF, and some proposals that might work well for small values of either (or both) of these parameters might not work well for very large values of these parameters. The texts says: As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, Should the "authorization" be "authentication" above. I agree with the use of "authorized" in the latter part of the sentence. later, the text says: After completing the in-band mechanism, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authorization mechanism. Did you mean authorization or authentication here? Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ____________________________________________________________________________ _____________________________________________ 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. From rlb@ipv.sx Thu Aug 1 02:06:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667A721F9BC2 for ; Thu, 1 Aug 2013 02:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va8fIsY86E1X for ; Thu, 1 Aug 2013 02:06:33 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id D80C821F9DB0 for ; Thu, 1 Aug 2013 02:06:20 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so3820066oag.1 for ; Thu, 01 Aug 2013 02:06:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XetcVzmbWulDN5+IJc5Il21aNIgPknECI5bC564EpGk=; b=m7rrD7CCnakZDizLJsBBpF7XK08XiuZGn3PAf9RHKeFWX0DunEZSb4MTG4NZHBDlR8 SqD/pHUcHwUtEaAJ+BCdpXr8JxnzAuYFI6vE5nj3K4MOSFFXhuJQ+kCxGLbTw3Sz3O3i Kbqv/ORQlI9+EhRYwHCc9iwqYZsK+61/yvWSZtQTlKm1wT/gx8Sr6WIpjaHy6XmZO/gk GYZ2DP2Joj5N4pstRkR5xCzr3EXYslGdtNEWrmn+XEQHvS0kdUS/iVlWDgSojsHuwSf5 /6paMDnTP8MSSdsX0EvjeqgjZsECjutxxP/wgz8EK+ib+ubzaE++rljE+WOIQMFAM2pa gDFA== MIME-Version: 1.0 X-Received: by 10.60.145.241 with SMTP id sx17mr380062oeb.57.1375347979410; Thu, 01 Aug 2013 02:06:19 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Thu, 1 Aug 2013 02:06:19 -0700 (PDT) X-Originating-IP: [128.89.254.150] In-Reply-To: <51FA14C9.6030903@dcrocker.net> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> <51F9F08C.3050700@dcrocker.net> <51FA14C9.6030903@dcrocker.net> Date: Thu, 1 Aug 2013 11:06:19 +0200 Message-ID: From: Richard Barnes To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7b5d474ac16fc104e2df2797 X-Gm-Message-State: ALoCoQnbmgzvZ96qt6+vfE+9Qi5sqicvcd/GSDw1J7BaQuneeHdGCYgFCwUaUvDzBQGUhUsk7U3t Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:06:41 -0000 --047d7b5d474ac16fc104e2df2797 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker wrote: > On 8/1/2013 9:26 AM, Richard Barnes wrote: > >> >> That's why I didn't propose putting it in the charter :) Obviously, we >> will try to clarify this in the charter. >> > > > Color me even more confused than usual (and that's going some.) > > Advice from the cognizant AD about what technical issues to "consider" > when working is usually treated as definitive direction, absent an > overriding appeal (which isn't ever requested, nevermind sustained.) > That's an overstatement. To quote the Tao: "Many people look at the ADs as somewhat godlike creatures ... However, most ADs are nearly indistinguishable from mere mortals and rarely speak from mountaintops." More to the point, I didn't mean it that way. That's why, for example, I said "I would encourage..." and not "Thou shalt..." I consider the charter to be the real commitment. Perhaps you could respond to the substance of the concern I raised in my > previous note? I take this to mean your concern that my "keep in mind" suggestion would encourage people to work on things in parallel rather than sequence. The intent is actually the opposite, to help people get interested in out-of-band more engaged in in-band. If the in-band solution requires parts (A,B,C) and out-of-band requires (A,B,D), then people interested in out-of-band should be interested in A and B, and not just checked out of the WG until in-band is done. --Richard > > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --047d7b5d474ac16fc104e2df2797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker <dhc@dcrocker= .net> wrote:
On 8/1/2013 9:26 AM, Richard Barnes wrot= e:

That's why I didn't propose putting it in the charter :) =A0Obvious= ly, we
will try to clarify this in the charter.


Color me even more confused than usual (and that's going some.)

Advice from the cognizant AD about what technical issues to "consider&= quot; when working is usually treated as definitive direction, absent an ov= erriding appeal (which isn't ever requested, nevermind sustained.)

That's an overstatement. =A0To quote t= he Tao:=A0
"Many people look at the ADs as somewhat godlike = creatures ... However, most ADs are nearly indistinguishable from mere mort= als and rarely speak from mountaintops."=A0

More to the point, I didn't mean it that way. =A0Th= at's why, for example, I said "I would encourage..." and not = "Thou shalt..." =A0I consider the charter to be the real commitme= nt.

=A0

Perhaps you could respond to the substance of the concern I raised in my pr= evious note?

I take this to mean your conce= rn that my "keep in mind" suggestion would encourage people to wo= rk on things in parallel rather than sequence.

The intent is actually the opposite, to help people get= interested in out-of-band more engaged in in-band. =A0If the in-band solut= ion requires parts (A,B,C) and out-of-band requires (A,B,D), then people in= terested in out-of-band should be interested in A and B, and not just check= ed out of the WG until in-band is done.

--Richard

=A0


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--047d7b5d474ac16fc104e2df2797-- From dhc@dcrocker.net Thu Aug 1 02:18:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D448B21E8096 for ; Thu, 1 Aug 2013 02:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ql2jXv60W0u for ; Thu, 1 Aug 2013 02:18:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E163D21E80AC for ; Thu, 1 Aug 2013 02:18:38 -0700 (PDT) Received: from [130.129.84.47] (dhcp-542f.meeting.ietf.org [130.129.84.47]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r719IV0Z001955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 02:18:36 -0700 Message-ID: <51FA27E1.2010703@dcrocker.net> Date: Thu, 01 Aug 2013 11:18:25 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Richard Barnes References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> <51F9F08C.3050700@dcrocker.net> <51FA14C9.6030903@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 01 Aug 2013 02:18:37 -0700 (PDT) Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:18:53 -0000 On 8/1/2013 11:06 AM, Richard Barnes wrote: > On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker > wrote: > Advice from the cognizant AD about what technical issues to > "consider" when working is usually treated as definitive direction, > absent an overriding appeal (which isn't ever requested, nevermind > sustained.) Philosphy first, then wg pragmatics... > That's an overstatement. To quote the Tao: > "Many people look at the ADs as somewhat godlike creatures ... However, > most ADs are nearly indistinguishable from mere mortals and rarely speak > from mountaintops." The Tao is (correctly in my view) trying to counter some natural tendencies to assign that godlike status to ADs. There was less reticence to beat the crap out of an AD (in strictly polite and virtual ways, of course) back when I was an AD, 20 years ago... but the IETF has become more like the real world, since then. > More to the point, I didn't mean it that way. That's why, for example, > I said "I would encourage..." and not "Thou shalt..." I consider the > charter to be the real commitment. Vint Cerf has an anecdote about a Colonel newly raised to General, who arrives at his first assignment, a military base. The car stops in front of HQ and as he gets out, he looks nearby and mutters "oh, a fire hydrant." At the end of the day, when he exits HQ to the car, he discovers that the hydrant has been removed. From generals, any utterance carries import. While many of us are less intimidated by those in lofty IETF positions that we perhaps should be, many others are more intimidated. To the point: An AD asserting what amounts to engineering guidance at the start of an effort -- especially when it pertains to an existing point of controversy amongst competent proponents on both sides -- strikes me as problematic to wg process, which is why I raised a concern. I'm not in the least concerned about your or anyone else's motives; everyone wants good stuff to happen. My concern is with the mere potential of constraining legitimate debate. > Perhaps you could respond to the substance of the concern I raised > in my previous note? > > I take this to mean your concern that my "keep in mind" suggestion would > encourage people to work on things in parallel rather than sequence. > > The intent is actually the opposite, to help people get interested in > out-of-band more engaged in in-band. Oh. Well, that's certainly a helpful goal, of course. But yes, I read your note quite differently, and from assorted separate conversations, I fear others also might have. > If the in-band solution requires > parts (A,B,C) and out-of-band requires (A,B,D), then people interested > in out-of-band should be interested in A and B, and not just checked out > of the WG until in-band is done. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Thu Aug 1 02:32:06 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD20D21F9E3A for ; Thu, 1 Aug 2013 02:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.271 X-Spam-Level: X-Spam-Status: No, score=-6.271 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7diJfPHY06x for ; Thu, 1 Aug 2013 02:32:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id BC70821F9EC3 for ; Thu, 1 Aug 2013 02:29:47 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r719TeM8027019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Aug 2013 09:29:40 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r719TcQl012525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 09:29:39 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r719TccR002809; Thu, 1 Aug 2013 09:29:38 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Aug 2013 02:29:38 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 1 Aug 2013 05:29:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> <51F9F08C.3050700@dcrocker.net> <51FA14C9.6030903@dcrocker.net> To: Richard Barnes X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: IETF STIR Mail List , Russ Housley , Dave Crocker Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:32:06 -0000 I think the concern, and I have it too, is that when one mixes oil and = water in a working group there are likely to be (1) differing views of = what's acceptable/not in terms of threats, deployment models and = protocols, and operation/management of it, and (2) cases of contention = for the same resources, such as vying for time in WG meetings. My interpretation of the charter is that if such things happen, then = in-band wins; once in-band is submitted to IESG, out-of-band gets all = the time. For now we can talk about both in mailing list, and of course = people can continue to work on out-of-band, discuss it in WG meetings if = there's time, etc. And when we work on our documents we have to keep = out-of-band in mind... although if we do find there're some big = differences or more documentation work required due to out-of-band, then = my assumption is we'd separate the out-of-band into separate docs to = work on later. -hadriel On Aug 1, 2013, at 5:06 AM, Richard Barnes wrote: > On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker wrote: > On 8/1/2013 9:26 AM, Richard Barnes wrote: >=20 > That's why I didn't propose putting it in the charter :) Obviously, = we > will try to clarify this in the charter. >=20 >=20 > Color me even more confused than usual (and that's going some.) >=20 > Advice from the cognizant AD about what technical issues to "consider" = when working is usually treated as definitive direction, absent an = overriding appeal (which isn't ever requested, nevermind sustained.) >=20 > That's an overstatement. To quote the Tao:=20 > "Many people look at the ADs as somewhat godlike creatures ... = However, most ADs are nearly indistinguishable from mere mortals and = rarely speak from mountaintops."=20 >=20 > More to the point, I didn't mean it that way. That's why, for = example, I said "I would encourage..." and not "Thou shalt..." I = consider the charter to be the real commitment. >=20 > =20 >=20 > Perhaps you could respond to the substance of the concern I raised in = my previous note? >=20 > I take this to mean your concern that my "keep in mind" suggestion = would encourage people to work on things in parallel rather than = sequence. >=20 > The intent is actually the opposite, to help people get interested in = out-of-band more engaged in in-band. If the in-band solution requires = parts (A,B,C) and out-of-band requires (A,B,D), then people interested = in out-of-band should be interested in A and B, and not just checked out = of the WG until in-band is done. >=20 > --Richard >=20 > =20 >=20 >=20 > d/ >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Thu Aug 1 02:42:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A7421F84EF for ; Thu, 1 Aug 2013 02:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.82 X-Spam-Level: X-Spam-Status: No, score=-105.82 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PtMblpN1RQT for ; Thu, 1 Aug 2013 02:42:45 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8893921F84D9 for ; Thu, 1 Aug 2013 02:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1375350126; x=1690708094; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=fwcQlprgUy sB3JjbuZLi7S0kumQc3w4lFl6h0P1kmSQ=; b=EqCAeffsdSmjhBdt4K6jO6DNs/ rK+4g0wfGN4OANbSn9NcJBCsMe6+8PDEbDNyADwL6kbKKMkmbS4WFX8asWPg== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.23251357; Thu, 01 Aug 2013 05:42:05 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.178]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 05:42:27 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Richard Barnes Thread-Topic: [stir] Including out-of-band in the Charter Thread-Index: AQHOjgHYkU1jFOUfFEaL9GSjhRT9zJl/LbeAgAAFOQCAAA0JAIAAGLCAgAAEQACAAACbAIAAQx0AgAB0mgCAACK1AIAACH6AgAATYYCAAAaBAIAAJRsA Date: Thu, 1 Aug 2013 09:42:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.129.27] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: f9FHCcEItyldnN14QUlxuQ== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List , Russ Housley , Dave Crocker Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:42:49 -0000 I think what's important are the points we discussed in the BoF: that having both of these mechanisms under development in the same venue lets us reuse critical components of the architecture, avoid duplication of effort, and scope what falls under the purview of one approach or the other. That means that we pursue in-band mindful of the fact that out-of-band is coming, and yes, when defining reusable components, we ideally find designs for them that will accommodate both in-band and out-of-band. Jon Peterson Neustar, inc. On 8/1/13 11:29 AM, "Hadriel Kaplan" wrote: > >I think the concern, and I have it too, is that when one mixes oil and >water in a working group there are likely to be (1) differing views of >what's acceptable/not in terms of threats, deployment models and >protocols, and operation/management of it, and (2) cases of contention >for the same resources, such as vying for time in WG meetings. > >My interpretation of the charter is that if such things happen, then >in-band wins; once in-band is submitted to IESG, out-of-band gets all the >time. For now we can talk about both in mailing list, and of course >people can continue to work on out-of-band, discuss it in WG meetings if >there's time, etc. And when we work on our documents we have to keep >out-of-band in mind... although if we do find there're some big >differences or more documentation work required due to out-of-band, then >my assumption is we'd separate the out-of-band into separate docs to work >on later. > >-hadriel > > >On Aug 1, 2013, at 5:06 AM, Richard Barnes wrote: > >> On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker wrote: >> On 8/1/2013 9:26 AM, Richard Barnes wrote: >>=20 >> That's why I didn't propose putting it in the charter :) Obviously, we >> will try to clarify this in the charter. >>=20 >>=20 >> Color me even more confused than usual (and that's going some.) >>=20 >> Advice from the cognizant AD about what technical issues to "consider" >>when working is usually treated as definitive direction, absent an >>overriding appeal (which isn't ever requested, nevermind sustained.) >>=20 >> That's an overstatement. To quote the Tao: >> "Many people look at the ADs as somewhat godlike creatures ... However, >>most ADs are nearly indistinguishable from mere mortals and rarely speak >>from mountaintops." >>=20 >> More to the point, I didn't mean it that way. That's why, for example, >>I said "I would encourage..." and not "Thou shalt..." I consider the >>charter to be the real commitment. >>=20 >> =20 >>=20 >> Perhaps you could respond to the substance of the concern I raised in >>my previous note? >>=20 >> I take this to mean your concern that my "keep in mind" suggestion >>would encourage people to work on things in parallel rather than >>sequence. >>=20 >> The intent is actually the opposite, to help people get interested in >>out-of-band more engaged in in-band. If the in-band solution requires >>parts (A,B,C) and out-of-band requires (A,B,D), then people interested >>in out-of-band should be interested in A and B, and not just checked out >>of the WG until in-band is done. >>=20 >> --Richard >>=20 >> =20 >>=20 >>=20 >> d/ >>=20 >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From md3135@att.com Thu Aug 1 02:50:04 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C19421F99E9 for ; Thu, 1 Aug 2013 02:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKaius7lrXlX for ; Thu, 1 Aug 2013 02:49:58 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6C21F9AD1 for ; Thu, 1 Aug 2013 02:49:58 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 64f2af15.6d834940.6815362.00-525.18831850.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 01 Aug 2013 09:49:58 +0000 (UTC) X-MXL-Hash: 51fa2f461bb36557-9a07fb63ab5c645f96b74f43757434506d6127c6 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e3f2af15.0.6815334.00-436.18831777.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 01 Aug 2013 09:49:55 +0000 (UTC) X-MXL-Hash: 51fa2f43182ed7e2-2bdab5cd17e53092ddc6bf9e1b040231d154f24b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r719noW0012041; Thu, 1 Aug 2013 05:49:50 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r719ncJw011981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 05:49:39 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 1 Aug 2013 09:49:20 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 05:49:20 -0400 From: "DOLLY, MARTIN C" To: "Peterson, Jon" , Hadriel Kaplan , Richard Barnes Thread-Topic: [stir] Including out-of-band in the Charter Thread-Index: AQHOjgHYIf9pO0TW2UGzL3AJe1O8VZl/LbeAgAAFOQCAAA0JAIAAGLCAgAAEQACAAACbAIAAQx0AgAB0mgCAACK1AIAACH6AgAATYYCAAAaBAIAAJRsA//+cxfA= Date: Thu, 1 Aug 2013 09:49:19 +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.175.94.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=gZFlcKY5e7cA:10 a=fAMK-m9FHcUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ypAo7WP30rwA:10 a=48vgC7mUAAAA:8 a=yPCof4ZbAAAA:8] X-AnalysisOut: [ a=b8OvNEjoAAAA:8 a=k7Ga1wGzAAAA:8 a=HDDWjcvXpoYWUgqjB5QA:] X-AnalysisOut: [9 a=CjuIK1q_8ugA:10 a=ClmATp4dOM8A:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [7DSvI1NPTFQA:10 a=E1Snkw02GREA:10 a=JB4ST2A_A5bS2kwi:21 a=] X-AnalysisOut: [53InDR77JhsP2dLp:21] Cc: IETF STIR Mail List , Russ Housley , Dave Crocker Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:50:04 -0000 I believe the FCC wants something will be deployed versus just placed on th= e IETF RFC shelf, never to see a deployment light of day.... -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pet= erson, Jon Sent: Thursday, August 01, 2013 5:42 AM To: Hadriel Kaplan; Richard Barnes Cc: IETF STIR Mail List; Russ Housley; Dave Crocker Subject: Re: [stir] Including out-of-band in the Charter I think what's important are the points we discussed in the BoF: that having both of these mechanisms under development in the same venue lets us reuse critical components of the architecture, avoid duplication of effort, and scope what falls under the purview of one approach or the other. That means that we pursue in-band mindful of the fact that out-of-band is coming, and yes, when defining reusable components, we ideally find designs for them that will accommodate both in-band and out-of-band. Jon Peterson Neustar, inc. On 8/1/13 11:29 AM, "Hadriel Kaplan" wrote: > >I think the concern, and I have it too, is that when one mixes oil and >water in a working group there are likely to be (1) differing views of >what's acceptable/not in terms of threats, deployment models and >protocols, and operation/management of it, and (2) cases of contention >for the same resources, such as vying for time in WG meetings. > >My interpretation of the charter is that if such things happen, then >in-band wins; once in-band is submitted to IESG, out-of-band gets all the >time. For now we can talk about both in mailing list, and of course >people can continue to work on out-of-band, discuss it in WG meetings if >there's time, etc. And when we work on our documents we have to keep >out-of-band in mind... although if we do find there're some big >differences or more documentation work required due to out-of-band, then >my assumption is we'd separate the out-of-band into separate docs to work >on later. > >-hadriel > > >On Aug 1, 2013, at 5:06 AM, Richard Barnes wrote: > >> On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker wrote: >> On 8/1/2013 9:26 AM, Richard Barnes wrote: >>=20 >> That's why I didn't propose putting it in the charter :) Obviously, we >> will try to clarify this in the charter. >>=20 >>=20 >> Color me even more confused than usual (and that's going some.) >>=20 >> Advice from the cognizant AD about what technical issues to "consider" >>when working is usually treated as definitive direction, absent an >>overriding appeal (which isn't ever requested, nevermind sustained.) >>=20 >> That's an overstatement. To quote the Tao: >> "Many people look at the ADs as somewhat godlike creatures ... However, >>most ADs are nearly indistinguishable from mere mortals and rarely speak >>from mountaintops." >>=20 >> More to the point, I didn't mean it that way. That's why, for example, >>I said "I would encourage..." and not "Thou shalt..." I consider the >>charter to be the real commitment. >>=20 >> =20 >>=20 >> Perhaps you could respond to the substance of the concern I raised in >>my previous note? >>=20 >> I take this to mean your concern that my "keep in mind" suggestion >>would encourage people to work on things in parallel rather than >>sequence. >>=20 >> The intent is actually the opposite, to help people get interested in >>out-of-band more engaged in in-band. If the in-band solution requires >>parts (A,B,C) and out-of-band requires (A,B,D), then people interested >>in out-of-band should be interested in A and B, and not just checked out >>of the WG until in-band is done. >>=20 >> --Richard >>=20 >> =20 >>=20 >>=20 >> d/ >>=20 >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From rlb@ipv.sx Thu Aug 1 05:13:52 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A74321E8105 for ; Thu, 1 Aug 2013 05:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLt9oW71tLDD for ; Thu, 1 Aug 2013 05:13:48 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id 66E7511E80FA for ; Thu, 1 Aug 2013 05:12:40 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so3592943obc.6 for ; Thu, 01 Aug 2013 05:12:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=q2zldDWgAhEFfEAZOaYm1VMg5vlVn9xkPLObBcDHSEY=; b=MRCnWzFqkoKB0+3GIxZchGs6+WjmLG5j1XZi65OXT0wJp4va97NPeIr7eZN7UmHRsG kc1q4XOmrYw196i+Z5QUwf8RzLa9U2HggZhthkkSsKz6brwvkA07ktWMrAdxAepxEZON TtLwpcOgnLupy1fJ4WXufas+GBmOWuouC7UF5P84Wq21o8h+8ng1HEJvbVqj1yITWSD+ 27N6zqVser2up0a38cMIPVrWRIU9e9/A/pdTArmrEyDBn2yvJyuzAMrA568NQi7ZNF3l Jr5kMoat8Eo0yEsdMjyWsKHUbGAjFjTXUbAlmsTozJju2U/djNZfliZoiZRhJhnytyCl dGxA== MIME-Version: 1.0 X-Received: by 10.182.38.228 with SMTP id j4mr883783obk.94.1375359159068; Thu, 01 Aug 2013 05:12:39 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Thu, 1 Aug 2013 05:12:38 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:f466:6c65:b20d:90f6] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> <51F9F08C.3050700@dcrocker.net> <51FA14C9.6030903@dcrocker.net> Date: Thu, 1 Aug 2013 14:12:38 +0200 Message-ID: From: Richard Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=001a11c2f3a61d6e0e04e2e1c268 X-Gm-Message-State: ALoCoQl/bpuZPPKnNAVYHg+Atlg8T+NYWq+QZ4HNQY9RTIQqCOkPYz6xqJ5RreXLU7Vm0FnQhx+r Cc: IETF STIR Mail List , Russ Housley , Dave Crocker Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:13:52 -0000 --001a11c2f3a61d6e0e04e2e1c268 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 1, 2013 at 11:29 AM, Hadriel Kaplan wrote: > > I think the concern, and I have it too, is that when one mixes oil and > water in a working group there are likely to be (1) differing views of > what's acceptable/not in terms of threats, deployment models and protocols, > and operation/management of it, and (2) cases of contention for the same > resources, such as vying for time in WG meetings. > > My interpretation of the charter is that if such things happen, then > in-band wins; once in-band is submitted to IESG, out-of-band gets all the > time. For now we can talk about both in mailing list, and of course people > can continue to work on out-of-band, discuss it in WG meetings if there's > time, etc. And when we work on our documents we have to keep out-of-band > in mind... although if we do find there're some big differences or more > documentation work required due to out-of-band, then my assumption is we'd > separate the out-of-band into separate docs to work on later. > Thanks, Hadriel. That matches my thinking. --Richard > > -hadriel > > > On Aug 1, 2013, at 5:06 AM, Richard Barnes wrote: > > > On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker wrote: > > On 8/1/2013 9:26 AM, Richard Barnes wrote: > > > > That's why I didn't propose putting it in the charter :) Obviously, we > > will try to clarify this in the charter. > > > > > > Color me even more confused than usual (and that's going some.) > > > > Advice from the cognizant AD about what technical issues to "consider" > when working is usually treated as definitive direction, absent an > overriding appeal (which isn't ever requested, nevermind sustained.) > > > > That's an overstatement. To quote the Tao: > > "Many people look at the ADs as somewhat godlike creatures ... However, > most ADs are nearly indistinguishable from mere mortals and rarely speak > from mountaintops." > > > > More to the point, I didn't mean it that way. That's why, for example, > I said "I would encourage..." and not "Thou shalt..." I consider the > charter to be the real commitment. > > > > > > > > Perhaps you could respond to the substance of the concern I raised in my > previous note? > > > > I take this to mean your concern that my "keep in mind" suggestion would > encourage people to work on things in parallel rather than sequence. > > > > The intent is actually the opposite, to help people get interested in > out-of-band more engaged in in-band. If the in-band solution requires > parts (A,B,C) and out-of-band requires (A,B,D), then people interested in > out-of-band should be interested in A and B, and not just checked out of > the WG until in-band is done. > > > > --Richard > > > > > > > > > > d/ > > > > > > -- > > Dave Crocker > > Brandenburg InternetWorking > > bbiw.net > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > --001a11c2f3a61d6e0e04e2e1c268 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 1, 2013 at 11:29 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

I think the concern, and I have it too, is that when one mixes oil and wate= r in a working group there are likely to be (1) differing views of what'= ;s acceptable/not in terms of threats, deployment models and protocols, and= operation/management of it, and (2) cases of contention for the same resou= rces, such as vying for time in WG meetings.

My interpretation of the charter is that if such things happen, then in-ban= d wins; once in-band is submitted to IESG, out-of-band gets all the time. = =A0For now we can talk about both in mailing list, and of course people can= continue to work on out-of-band, discuss it in WG meetings if there's = time, etc. =A0And when we work on our documents we have to keep out-of-band= in mind... although if we do find there're some big differences or mor= e documentation work required due to out-of-band, then my assumption is we&= #39;d separate the out-of-band into separate docs to work on later.

Thanks, Hadriel. =A0That matches my thinki= ng.

--Richard


<= div>=A0

-hadriel


On Aug 1, 2013, at 5:06 AM, Richard Barnes <rlb@ipv.sx> wrote:

> On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker <dhc@dcrocker.net> wrote:
> On 8/1/2013 9:26 AM, Richard Barnes wrote:
>
> That's why I didn't propose putting it in the charter :) =A0Ob= viously, we
> will try to clarify this in the charter.
>
>
> Color me even more confused than usual (and that's going some.) >
> Advice from the cognizant AD about what technical issues to "cons= ider" when working is usually treated as definitive direction, absent = an overriding appeal (which isn't ever requested, nevermind sustained.)=
>
> That's an overstatement. =A0To quote the Tao:
> "Many people look at the ADs as somewhat godlike creatures ... Ho= wever, most ADs are nearly indistinguishable from mere mortals and rarely s= peak from mountaintops."
>
> More to the point, I didn't mean it that way. =A0That's why, f= or example, I said "I would encourage..." and not "Thou shal= t..." =A0I consider the charter to be the real commitment.
>
>
>
> Perhaps you could respond to the substance of the concern I raised in = my previous note?
>
> I take this to mean your concern that my "keep in mind" sugg= estion would encourage people to work on things in parallel rather than seq= uence.
>
> The intent is actually the opposite, to help people get interested in = out-of-band more engaged in in-band. =A0If the in-band solution requires pa= rts (A,B,C) and out-of-band requires (A,B,D), then people interested in out= -of-band should be interested in A and B, and not just checked out of the W= G until in-band is done.
>
> --Richard
>
>
>
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> __________________= _____________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


--001a11c2f3a61d6e0e04e2e1c268-- From michael.hammer@yaanatech.com Thu Aug 1 06:51:54 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F0D21F9AED for ; Thu, 1 Aug 2013 06:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4G7eklovPCQ for ; Thu, 1 Aug 2013 06:51:29 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 11AEE21E813F for ; Thu, 1 Aug 2013 06:51:15 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 1 Aug 2013 06:51:12 -0700 From: Michael Hammer To: "gordon.lennox.13@gmail.com" , "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] Moving from BOF to Charter Thread-Index: AQHOjfnsWvtGWyhvPke71SQYAe9TS5l/Xk+AgAAT1ICAAQRpAP//6RJw Date: Thu, 1 Aug 2013 13:51:12 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC20FF8@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> <58E52A04-537D-4DC4-8AD1-892185C0993F@gmail.com> In-Reply-To: <58E52A04-537D-4DC4-8AD1-892185C0993F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.170] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A3_01CE8E9C.A72ADE90" MIME-Version: 1.0 Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:51:54 -0000 ------=_NextPart_000_00A3_01CE8E9C.A72ADE90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard S., one clarification. By privacy below, I assume you mean the American concept of "the right to be left alone", meaning not bothered by anonymous strangers calling you. I wonder if the CoE covers that. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Gordon Lennox Sent: Thursday, August 01, 2013 4:10 AM To: Richard Shockey; IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter On 31 Jul, 2013, at 18:38, Richard Shockey wrote: > I agree though as Lucy Lynch pointed out in calling out attention to > the privacy problem there may be an interesting dimension to this. > When does the right to privacy trump the right to be anonymous? We > are confronted with a situation where a genuine perceived need for > anonymous communications identity for some has become a shield for criminal behavior. The Council of Europe is an international organisation promoting co-operation between all countries of Europe in the areas of legal standards, human rights, democratic development, the rule of law and cultural co-operation. It is an entirely separate body from the European Union (EU). Nearly all European countries are in the CoE including Russia. But the US and Canada are also involved. Certain CoE conventions have been opened to signature by non-members. Canada, Japan, South Africa and the United States all signed the CoE Cybercrime Convention, for example. About ten years ago the CoE Committee of Ministers adopted a Declaration on freedom of communication on the Internet. That included: "Principle 7: Anonymity In order to ensure protection against online surveillance and to enhance the free expression of information and ideas, member states should respect the will of users of the Internet not to disclose their identity. This does not prevent member states from taking measures and co-operating in order to trace those responsible for criminal acts, in accordance with national law, the Convention for the Protection of Human Rights and Fundamental Freedoms and other international agreements in the fields of justice and the police." I am sure there is more from the CoE on this. Gordon _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00A3_01CE8E9C.A72ADE90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw MTEzNTExMVowIwYJKoZIhvcNAQkEMRYEFMyauU1GKxTTVxFZTjoMMynefTgKMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAKlSShk3CHG08uWP2VbGhyMrCZwI2pYvme4EAZt9v clk57jljfYCQW9LYW0cwfH9PoLdkWEEva4wLoIer620yh6x4LX8uotNjjHjRArTR4YKN4paS2Xi9 EyX47vhnsX3iqZh7ZTNtbTzVl0beKtI7b3Ne2aJq+LbgL5NlaIDWHOLdkyqbEAjG5u47XEnsuI2f S79ZgAQLnmdFAii7Rmm+JtZtWtGcVUwNdRhfRJLK78gRowoe/ItMOvy1hZ9VQfoHj6z2LpH7POf/ HJdK7XEhmy8gpyV9m7mxvYmIcQSmtYTh/l5Yq9qtFzBB69R8woa/XFBat6mUTEU1HMGkaF4HPwAA AAAAAA== ------=_NextPart_000_00A3_01CE8E9C.A72ADE90-- From richard@shockey.us Thu Aug 1 07:43:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B052511E8175 for ; Thu, 1 Aug 2013 07:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2o-n4D6UAhf for ; Thu, 1 Aug 2013 07:43:15 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 5ACA611E8189 for ; Thu, 1 Aug 2013 07:42:38 -0700 (PDT) Received: (qmail 30410 invoked by uid 0); 1 Aug 2013 14:42:14 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 1 Aug 2013 14:42:14 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=pkpoaA7WRzFVK0ZF/05T/QleRUwbNJzx39uFZHABMLE=; b=FeM4G2MO/I9CBjGVvNUhNi3reIpkzevR8RcNA0TwBGyVa5xzbOw8hpfY9UeOYb5qFwrSb9bF5yOD0biX4oFVJ7pgr+cgXtv99E6QxgnQaUJy1nVqkGQj4XNqJpbnhTT4; Received: from [46.189.28.45] (port=58129 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4u4z-00065J-Ij; Thu, 01 Aug 2013 08:42:13 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> <58E52A04-537D-4DC4-8AD1-892185C0993F@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBC20FF8@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC20FF8@EX2K10MB1.corp.yaanatech.com> Date: Thu, 1 Aug 2013 10:42:11 -0400 Message-ID: <012101ce8ec5$4faf40b0$ef0dc210$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAS+naHgDKkDi7QG6uZwpmGpesLA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 46.189.28.45 authed with richard@shockey.us} Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:43:21 -0000 My question exactly ... especially volations of the Do Not Call Lists. Especially by the political class but alas that is not always possible. Canada has a more enlightened view of this. http://news.nationalpost.com/2013/07/26/ndp-mp-paul-dewar-slapped-with-7000- fine-over-campaign-robocalls/ -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, August 01, 2013 9:51 AM To: gordon.lennox.13@gmail.com; richard@shockey.us; stir@ietf.org Subject: RE: [stir] Moving from BOF to Charter Richard S., one clarification. By privacy below, I assume you mean the American concept of "the right to be left alone", meaning not bothered by anonymous strangers calling you. I wonder if the CoE covers that. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Gordon Lennox Sent: Thursday, August 01, 2013 4:10 AM To: Richard Shockey; IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter On 31 Jul, 2013, at 18:38, Richard Shockey wrote: > I agree though as Lucy Lynch pointed out in calling out attention to > the privacy problem there may be an interesting dimension to this. > When does the right to privacy trump the right to be anonymous? We > are confronted with a situation where a genuine perceived need for > anonymous communications identity for some has become a shield for criminal behavior. The Council of Europe is an international organisation promoting co-operation between all countries of Europe in the areas of legal standards, human rights, democratic development, the rule of law and cultural co-operation. It is an entirely separate body from the European Union (EU). Nearly all European countries are in the CoE including Russia. But the US and Canada are also involved. Certain CoE conventions have been opened to signature by non-members. Canada, Japan, South Africa and the United States all signed the CoE Cybercrime Convention, for example. About ten years ago the CoE Committee of Ministers adopted a Declaration on freedom of communication on the Internet. That included: "Principle 7: Anonymity In order to ensure protection against online surveillance and to enhance the free expression of information and ideas, member states should respect the will of users of the Internet not to disclose their identity. This does not prevent member states from taking measures and co-operating in order to trace those responsible for criminal acts, in accordance with national law, the Convention for the Protection of Human Rights and Fundamental Freedoms and other international agreements in the fields of justice and the police." I am sure there is more from the CoE on this. Gordon _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From tony@yaanatech.com Thu Aug 1 17:25:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8A511E8379 for ; Thu, 1 Aug 2013 17:25:40 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4++XkEGPd1A for ; Thu, 1 Aug 2013 17:25:29 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE2A21E8051 for ; Thu, 1 Aug 2013 16:36:26 -0700 (PDT) Received: from [192.168.0.11] (pool-71-171-119-184.clppva.fios.verizon.net [71.171.119.184]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 6C7C95808A; Thu, 1 Aug 2013 23:36:24 +0000 (UTC) Date: Thu, 01 Aug 2013 19:36:22 -0400 Message-ID: From: Tony Rutkowski To: Mike Hammer MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: stir@ietf.org, gordon.lennox.13@gmail.com, " richard@shockey.us" Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 00:25:40 -0000 SW4gRXVyb3BlIGFuZCBtb3N0IG90aGVyIGp1cmlzZGljdGlvbnMsIHRoZSBEYXRhIFJldGVudGlv biBEaXJlY3RpdmVzIHRydW1wIHRoZSB2YWd1ZSBmZWVsIGdvb2QgYW5vbnltaXphdGlvbiBzdHVm Zi4KCk1pY2hhZWwgSGFtbWVyIDxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tPiB3cm90ZToK Cj5SaWNoYXJkIFMuLCBvbmUgY2xhcmlmaWNhdGlvbi4KPgo+QnkgcHJpdmFjeSBiZWxvdywgSSBh c3N1bWUgeW91IG1lYW4gdGhlIEFtZXJpY2FuIGNvbmNlcHQgb2YgInRoZSByaWdodCB0byBiZQo+ bGVmdCBhbG9uZSIsIG1lYW5pbmcgbm90IGJvdGhlcmVkIGJ5IGFub255bW91cyBzdHJhbmdlcnMg Y2FsbGluZyB5b3UuCj4KPkkgd29uZGVyIGlmIHRoZSBDb0UgY292ZXJzIHRoYXQuCj4KPk1pa2UK Pgo+Cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+RnJvbTogc3Rpci1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YKPkdvcmRvbiBM ZW5ub3gKPlNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDEsIDIwMTMgNDoxMCBBTQo+VG86IFJpY2hh cmQgU2hvY2tleTsgSUVURiBTVElSIE1haWwgTGlzdAo+U3ViamVjdDogUmU6IFtzdGlyXSBNb3Zp bmcgZnJvbSBCT0YgdG8gQ2hhcnRlcgo+Cj4KPk9uIDMxIEp1bCwgMjAxMywgYXQgMTg6MzgsIFJp Y2hhcmQgU2hvY2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPiB3cm90ZToKPgo+PiBJIGFncmVlIHRo b3VnaCBhcyBMdWN5IEx5bmNoIHBvaW50ZWQgb3V0IGluIGNhbGxpbmcgb3V0IGF0dGVudGlvbiB0 byAKPj4gdGhlIHByaXZhY3kgcHJvYmxlbSB0aGVyZSBtYXkgYmUgYW4gaW50ZXJlc3RpbmcgZGlt ZW5zaW9uIHRvIHRoaXMuIAo+PiBXaGVuIGRvZXMgdGhlIHJpZ2h0IHRvIHByaXZhY3kgdHJ1bXAg dGhlIHJpZ2h0IHRvIGJlIGFub255bW91cz8gIFdlIAo+PiBhcmUgY29uZnJvbnRlZCB3aXRoIGEg c2l0dWF0aW9uIHdoZXJlIGEgZ2VudWluZSBwZXJjZWl2ZWQgbmVlZCBmb3IgCj4+IGFub255bW91 cyBjb21tdW5pY2F0aW9ucyBpZGVudGl0eSBmb3Igc29tZSBoYXMgYmVjb21lIGEgc2hpZWxkIGZv cgo+Y3JpbWluYWwgYmVoYXZpb3IuCj4KPgo+VGhlIENvdW5jaWwgb2YgRXVyb3BlIGlzIGFuIGlu dGVybmF0aW9uYWwgb3JnYW5pc2F0aW9uIHByb21vdGluZwo+Y28tb3BlcmF0aW9uIGJldHdlZW4g YWxsIGNvdW50cmllcyBvZiBFdXJvcGUgaW4gdGhlIGFyZWFzIG9mIGxlZ2FsCj5zdGFuZGFyZHMs IGh1bWFuIHJpZ2h0cywgZGVtb2NyYXRpYyBkZXZlbG9wbWVudCwgdGhlIHJ1bGUgb2YgbGF3IGFu ZAo+Y3VsdHVyYWwgY28tb3BlcmF0aW9uLiBJdCBpcyBhbiBlbnRpcmVseSBzZXBhcmF0ZSBib2R5 IGZyb20gdGhlIEV1cm9wZWFuCj5VbmlvbiAoRVUpLiBOZWFybHkgYWxsIEV1cm9wZWFuIGNvdW50 cmllcyBhcmUgaW4gdGhlIENvRSBpbmNsdWRpbmcgUnVzc2lhLgo+QnV0IHRoZSBVUyBhbmQgQ2Fu YWRhIGFyZSBhbHNvIGludm9sdmVkLiBDZXJ0YWluIENvRSBjb252ZW50aW9ucyBoYXZlIGJlZW4K Pm9wZW5lZCB0byBzaWduYXR1cmUgYnkgbm9uLW1lbWJlcnMuIENhbmFkYSwgSmFwYW4sIFNvdXRo IEFmcmljYSBhbmQgdGhlCj5Vbml0ZWQgU3RhdGVzIGFsbCBzaWduZWQgdGhlIENvRSBDeWJlcmNy aW1lIENvbnZlbnRpb24sIGZvciBleGFtcGxlLgo+Cj5BYm91dCB0ZW4geWVhcnMgYWdvIHRoZSBD b0UgQ29tbWl0dGVlIG9mIE1pbmlzdGVycyBhZG9wdGVkIGEgRGVjbGFyYXRpb24gb24KPmZyZWVk b20gb2YgY29tbXVuaWNhdGlvbiBvbiB0aGUgSW50ZXJuZXQuCj4KPlRoYXQgaW5jbHVkZWQ6Cj4K PiJQcmluY2lwbGUgNzogQW5vbnltaXR5Cj4KPkluIG9yZGVyIHRvIGVuc3VyZSBwcm90ZWN0aW9u IGFnYWluc3Qgb25saW5lIHN1cnZlaWxsYW5jZSBhbmQgdG8gZW5oYW5jZSB0aGUKPmZyZWUgZXhw cmVzc2lvbiBvZiBpbmZvcm1hdGlvbiBhbmQgaWRlYXMsIG1lbWJlciBzdGF0ZXMgc2hvdWxkIHJl c3BlY3QgdGhlCj53aWxsIG9mIHVzZXJzIG9mIHRoZSBJbnRlcm5ldCBub3QgdG8gZGlzY2xvc2Ug dGhlaXIgaWRlbnRpdHkuIFRoaXMgZG9lcyBub3QKPnByZXZlbnQgbWVtYmVyIHN0YXRlcyBmcm9t IHRha2luZyBtZWFzdXJlcyBhbmQgY28tb3BlcmF0aW5nIGluIG9yZGVyIHRvCj50cmFjZSB0aG9z ZSByZXNwb25zaWJsZSBmb3IgY3JpbWluYWwgYWN0cywgaW4gYWNjb3JkYW5jZSB3aXRoIG5hdGlv bmFsIGxhdywKPnRoZSBDb252ZW50aW9uIGZvciB0aGUgUHJvdGVjdGlvbiBvZiBIdW1hbiBSaWdo dHMgYW5kIEZ1bmRhbWVudGFsIEZyZWVkb21zCj5hbmQgb3RoZXIgaW50ZXJuYXRpb25hbCBhZ3Jl ZW1lbnRzIGluIHRoZSBmaWVsZHMgb2YganVzdGljZSBhbmQgdGhlIHBvbGljZS4iCj4KPkkgYW0g c3VyZSB0aGVyZSBpcyBtb3JlIGZyb20gdGhlIENvRSBvbiB0aGlzLgo+Cj5Hb3Jkb24KPgo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPnN0aXIgbWFpbGlu ZyBsaXN0Cj5zdGlyQGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N0aXIKPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPnN0aXIgbWFpbGluZyBsaXN0Cj5zdGlyQGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0aXIK From acooper@cdt.org Thu Aug 1 20:56:18 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4042D11E80EF for ; Thu, 1 Aug 2013 20:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63xudX+bGqCv for ; Thu, 1 Aug 2013 20:56:14 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB3811E8180 for ; Thu, 1 Aug 2013 20:56:11 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 1 Aug 2013 23:56:09 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Alissa Cooper In-Reply-To: Date: Fri, 2 Aug 2013 05:56:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tony Rutkowski X-Mailer: Apple Mail (2.1499) Cc: stir@ietf.org, gordon.lennox.13@gmail.com, Mike Hammer , " richard@shockey.us" Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 03:56:18 -0000 Helpfully, we have our own guidelines and terminology that can be used = to discuss the privacy properties and trade-offs of the stir work: = . Section 7.4 may be particularly = key. Alissa On Aug 2, 2013, at 1:36 AM, Tony Rutkowski wrote: > In Europe and most other jurisdictions, the Data Retention Directives = trump the vague feel good anonymization stuff. >=20 > Michael Hammer wrote: >=20 >> Richard S., one clarification. >>=20 >> By privacy below, I assume you mean the American concept of "the = right to be >> left alone", meaning not bothered by anonymous strangers calling you. >>=20 >> I wonder if the CoE covers that. >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of >> Gordon Lennox >> Sent: Thursday, August 01, 2013 4:10 AM >> To: Richard Shockey; IETF STIR Mail List >> Subject: Re: [stir] Moving from BOF to Charter >>=20 >>=20 >> On 31 Jul, 2013, at 18:38, Richard Shockey = wrote: >>=20 >>> I agree though as Lucy Lynch pointed out in calling out attention to=20= >>> the privacy problem there may be an interesting dimension to this.=20= >>> When does the right to privacy trump the right to be anonymous? We=20= >>> are confronted with a situation where a genuine perceived need for=20= >>> anonymous communications identity for some has become a shield for >> criminal behavior. >>=20 >>=20 >> The Council of Europe is an international organisation promoting >> co-operation between all countries of Europe in the areas of legal >> standards, human rights, democratic development, the rule of law and >> cultural co-operation. It is an entirely separate body from the = European >> Union (EU). Nearly all European countries are in the CoE including = Russia. >> But the US and Canada are also involved. Certain CoE conventions have = been >> opened to signature by non-members. Canada, Japan, South Africa and = the >> United States all signed the CoE Cybercrime Convention, for example. >>=20 >> About ten years ago the CoE Committee of Ministers adopted a = Declaration on >> freedom of communication on the Internet. >>=20 >> That included: >>=20 >> "Principle 7: Anonymity >>=20 >> In order to ensure protection against online surveillance and to = enhance the >> free expression of information and ideas, member states should = respect the >> will of users of the Internet not to disclose their identity. This = does not >> prevent member states from taking measures and co-operating in order = to >> trace those responsible for criminal acts, in accordance with = national law, >> the Convention for the Protection of Human Rights and Fundamental = Freedoms >> and other international agreements in the fields of justice and the = police." >>=20 >> I am sure there is more from the CoE on this. >>=20 >> Gordon >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From acooper@cdt.org Thu Aug 1 21:09:37 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1AF11E81AC for ; Thu, 1 Aug 2013 21:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYY8+cMieeXr for ; Thu, 1 Aug 2013 21:09:33 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0065E11E81DE for ; Thu, 1 Aug 2013 21:09:31 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 2 Aug 2013 00:09:27 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Alissa Cooper In-Reply-To: Date: Fri, 2 Aug 2013 06:09:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F129E74-394F-470B-ACDE-130ED67E1241@cdt.org> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBC207BA@EX2K10MB1.corp.yaanatech.com> To: Brian Rosen X-Mailer: Apple Mail (2.1499) Cc: "stir@ietf.org" , Michael Hammer , "kent@bbn.com" , "richard@shockey.us" Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 04:09:37 -0000 On Jul 31, 2013, at 10:28 PM, Brian Rosen wrote: > With respect to privacy, I think there are two principles we ought to = explicitly agree to > 1) Anonymous calls, as already defined in SIP standards will still = work, which means they will not have a valid identiy > 2) the mechanisms we design will not reveal any more information than = a call without the mechanism would. +1 I don't think either of these are fully reflected in the charter at = present, but they should be. In particular, "This working group is not = chartered to mandate the presence of identity in SIP requests" makes it sound like it could be re-chartered = in the future to do so. The second principle above is also stronger than = "to the extent feasible [the WG] will find privacy-friendly solutions = that leak minimal information about calls to third parties." Alissa >=20 > The former is just some explici text that says the mechanism must not = be applied to calls to with the anonymous =46rom uri. The latter may = constrain the mechanisms some, but that is a good thing. >=20 > Brian >=20 > On Wednesday, July 31, 2013, Michael Hammer wrote: > All, >=20 > For security, an assessment of the degree to which a called party can > reasonably rely on the caller ID validation is in order. > But, it should probably contain the warning to users to still not = provide > any sensitive information when they are not the calling party, to be = safe. >=20 > While privacy is important, I believe that it could be secondary, = because, > if this is designed as an optional feature (user chooses what to = assert and > whether to sign or not) > such considerations are in the realm of the supplementary features = like CLIP > and CLIR. > The default may be to show and sign for the 99% with an opt-in to = suppress > for the corner cases that need it. > Privacy could also be modeled as an over-ride feature that allows a = party or > carrier to substitute an anonymous signature. >=20 > Bottom line, privacy is a derivative of the caller ID function. >=20 > Clearly there needs to be balance between the calling and called = parties. > Called parties are going to have to learn to automatically or manually = block > calls. >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Richard Shockey > Sent: Wednesday, July 31, 2013 12:38 PM > To: 'Stephen Kent'; 'IETF STIR Mail List' > Subject: Re: [stir] Moving from BOF to Charter >=20 >=20 > I agree though as Lucy Lynch pointed out in calling out attention to = the > privacy problem there may be an interesting dimension to this. When = does the > right to privacy trump the right to be anonymous? We are confronted = with a > situation where a genuine perceived need for anonymous communications > identity for some has become a shield for criminal behavior. >=20 > The other issue maybe ISOC can help us with this problem is we still = don't > have an idea of the scope of the problem beyond North America. Other > jurisdictions handle this differently and this is a perfect = opportunity to > encourage national regulators to engage with the IETF/ISOC in = investigating > these problems. >=20 > I would argue that what we are seeing in North America is the "Canary = in the > Coal Mine". >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Stephen Kent > Sent: Wednesday, July 31, 2013 11:27 AM > To: stir@ietf.org > Subject: Re: [stir] Moving from BOF to Charter >=20 > Russ, >=20 > As I mentioned at the mic, I'd like to see both a threat model and a = privacy > analysis as deliverables early in this process. >=20 > I also think we need to have a discussion about the size of the = population > of calling parties who will have credentials, and the size of the = verifiers > in the system. This seemed to be the source of some disagreement = during the > BoF, and some proposals that might work well for small values of = either (or > both) of these parameters might not work well for very large values of = these > parameters. >=20 > The texts says: >=20 > As its first work item, the working group will specify a SIP = header-based > authorization mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, >=20 > Should the "authorization" be "authentication" above. I agree with the = use > of "authorized" in the latter part of the sentence. >=20 > later, the text says: >=20 > After completing the in-band mechanism, the working group will = consider > session establishment where there are one or more non-SIP hops, most = likely > using an out-of-band authorization mechanism. >=20 > Did you mean authorization or authentication here? >=20 > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Sat Aug 3 02:25:16 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0887621F9E68 for ; Sat, 3 Aug 2013 02:25:16 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOMyGxpKvQAt for ; Sat, 3 Aug 2013 02:25:11 -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 B5D2611E810C for ; Sat, 3 Aug 2013 02:25:10 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Alissa Cooper , Brian Rosen Thread-Topic: [stir] Moving from BOF to Charter Thread-Index: AQHOjfnzqKBJtlavVEST8ooMdGvZdpl/LASAgAAT1ICAAAUmAIAAOyYAgAITHQCAAaYZeA== Date: Sat, 3 Aug 2013 09:25:07 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBC207BA@EX2K10MB1.corp.yaanatech.com> , <7F129E74-394F-470B-ACDE-130ED67E1241@cdt.org> In-Reply-To: <7F129E74-394F-470B-ACDE-130ED67E1241@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 09:25:16 -0000 Clearly, we need to reflect strong privacy goals in the charter. I'm slight= ly concerned about the second statement as there could be conceivable cases= where the certificate or public key reveals information about the caller's= *carrier*, particularly if that carrier chooses to re-use public keys acro= ss customers, as appears likely (and generally beyond the control of the ca= ller).=0A= =0A= A narrow interpretation could essentially rule out any mechanism that we ha= ve discussed, so maybe something like "reveal any more personal information= about the caller than a call" would address the concern without making the= problem impossible to solve.=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Alissa Coo= per [acooper@cdt.org]=0A= Sent: Friday, August 02, 2013 12:09 AM=0A= To: Brian Rosen=0A= Cc: stir@ietf.org; Michael Hammer; kent@bbn.com; richard@shockey.us=0A= Subject: Re: [stir] Moving from BOF to Charter=0A= =0A= On Jul 31, 2013, at 10:28 PM, Brian Rosen wrote:=0A= =0A= > With respect to privacy, I think there are two principles we ought to exp= licitly agree to=0A= > 1) Anonymous calls, as already defined in SIP standards will still work, = which means they will not have a valid identiy=0A= > 2) the mechanisms we design will not reveal any more information than a c= all without the mechanism would.=0A= =0A= +1=0A= =0A= I don't think either of these are fully reflected in the charter at present= , but they should be. In particular, "This working group is not chartered t= o mandate the presence of=0A= identity in SIP requests" makes it sound like it could be re-chartered in t= he future to do so. The second principle above is also stronger than "to th= e extent feasible [the WG] will find privacy-friendly solutions that leak m= inimal information about calls to third parties."=0A= =0A= Alissa=0A= =0A= >=0A= > The former is just some explici text that says the mechanism must not be = applied to calls to with the anonymous From uri. The latter may constrain = the mechanisms some, but that is a good thing.=0A= >=0A= > Brian=0A= >=0A= > On Wednesday, July 31, 2013, Michael Hammer wrote:=0A= > All,=0A= >=0A= > For security, an assessment of the degree to which a called party can=0A= > reasonably rely on the caller ID validation is in order.=0A= > But, it should probably contain the warning to users to still not provide= =0A= > any sensitive information when they are not the calling party, to be safe= .=0A= >=0A= > While privacy is important, I believe that it could be secondary, because= ,=0A= > if this is designed as an optional feature (user chooses what to assert a= nd=0A= > whether to sign or not)=0A= > such considerations are in the realm of the supplementary features like C= LIP=0A= > and CLIR.=0A= > The default may be to show and sign for the 99% with an opt-in to suppres= s=0A= > for the corner cases that need it.=0A= > Privacy could also be modeled as an over-ride feature that allows a party= or=0A= > carrier to substitute an anonymous signature.=0A= >=0A= > Bottom line, privacy is a derivative of the caller ID function.=0A= >=0A= > Clearly there needs to be balance between the calling and called parties.= =0A= > Called parties are going to have to learn to automatically or manually bl= ock=0A= > calls.=0A= >=0A= > Mike=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of= =0A= > Richard Shockey=0A= > Sent: Wednesday, July 31, 2013 12:38 PM=0A= > To: 'Stephen Kent'; 'IETF STIR Mail List'=0A= > Subject: Re: [stir] Moving from BOF to Charter=0A= >=0A= >=0A= > I agree though as Lucy Lynch pointed out in calling out attention to the= =0A= > privacy problem there may be an interesting dimension to this. When does = the=0A= > right to privacy trump the right to be anonymous? We are confronted with= a=0A= > situation where a genuine perceived need for anonymous communications=0A= > identity for some has become a shield for criminal behavior.=0A= >=0A= > The other issue maybe ISOC can help us with this problem is we still don'= t=0A= > have an idea of the scope of the problem beyond North America. Other=0A= > jurisdictions handle this differently and this is a perfect opportunity t= o=0A= > encourage national regulators to engage with the IETF/ISOC in investigati= ng=0A= > these problems.=0A= >=0A= > I would argue that what we are seeing in North America is the "Canary in = the=0A= > Coal Mine".=0A= >=0A= > -----Original Message-----=0A= > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of= =0A= > Stephen Kent=0A= > Sent: Wednesday, July 31, 2013 11:27 AM=0A= > To: stir@ietf.org=0A= > Subject: Re: [stir] Moving from BOF to Charter=0A= >=0A= > Russ,=0A= >=0A= > As I mentioned at the mic, I'd like to see both a threat model and a priv= acy=0A= > analysis as deliverables early in this process.=0A= >=0A= > I also think we need to have a discussion about the size of the populatio= n=0A= > of calling parties who will have credentials, and the size of the verifie= rs=0A= > in the system. This seemed to be the source of some disagreement during t= he=0A= > BoF, and some proposals that might work well for small values of either (= or=0A= > both) of these parameters might not work well for very large values of th= ese=0A= > parameters.=0A= >=0A= > The texts says:=0A= >=0A= > As its first work item, the working group will specify a SIP header-based= =0A= > authorization mechanism to verify the originator of a SIP session is=0A= > authorized to use the claimed source telephone number,=0A= >=0A= > Should the "authorization" be "authentication" above. I agree with the us= e=0A= > of "authorized" in the latter part of the sentence.=0A= >=0A= > later, the text says:=0A= >=0A= > After completing the in-band mechanism, the working group will consider= =0A= > session establishment where there are one or more non-SIP hops, most like= ly=0A= > using an out-of-band authorization mechanism.=0A= >=0A= > Did you mean authorization or authentication here?=0A= >=0A= > Steve=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= >=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= =0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From fas_vm@surguttel.ru Sun Aug 4 11:30:54 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7510B21F9E45 for ; Sun, 4 Aug 2013 11:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.981 X-Spam-Level: ** X-Spam-Status: No, score=2.981 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_50=0.001, FAKE_REPLY_C=2.012, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x-aBeGn+lQA for ; Sun, 4 Aug 2013 11:30:48 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 841CE21F9E39 for ; Sun, 4 Aug 2013 11:30:48 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id D3956513916; Mon, 5 Aug 2013 00:30:45 +0600 (YEKT) Received: from Gateway (unknown [151.252.67.49]) by mail.s86.ru (Postfix) with ESMTPA id 4D5A0513840; Mon, 5 Aug 2013 00:30:42 +0600 (YEKT) Message-ID: <7D8ECCC0A7324280A8C243CAAB895C93@Gateway> From: "Anton Tveretin" To: "Hadriel Kaplan" Date: Mon, 5 Aug 2013 00:26:03 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130804-0, 04.08.2013), Outbound message X-Antivirus-Status: Clean Cc: stir@ietf.org Subject: Re: [stir] draft-kaplan-stir-ikes-out X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 18:30:54 -0000 Hello, First, I thank you, Hadriel, for the work done. See my notes, though. Why should addresses be included into IKES? IMO that adds nothing but extra work for each validator. Chapter 11 (error): in DSS1, call termination is done with 3 messages (DISCONNECT/RELEASE/RELEASE COMPLETE). In H.225.0 call control, just one (RELEASE COMPLETE). This error must be corrected. H.225.0 call control contains h323-uu-pdu, which coexists with user-information, and thus it actually does not count to 131 bytes of ISDN User-to-User IE. So I think it is possible to combine all ISDN (ISUP, DSS1, H.225.0 CC). But, for H.323 it would be more critical to supply IKES in RAS (e.g. ARQ) and H.501 messages IMO. Yes, H.323 Forum might have a different opinion about H.323 dying. Anyway, H.323 users deserve new features, practice shows that. And what about other networks, e.g. GSM? Sincerely yours, Anton. From hadriel.kaplan@oracle.com Sun Aug 4 11:37:18 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1D721F9E7C for ; Sun, 4 Aug 2013 11:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1vfc0DmrVtv for ; Sun, 4 Aug 2013 11:37:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 51DA921F9E68 for ; Sun, 4 Aug 2013 11:37:13 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r74IbBhC012303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 4 Aug 2013 18:37:12 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r74IbAdd026601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 4 Aug 2013 18:37:11 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r74IbAxP016296 for ; Sun, 4 Aug 2013 18:37:10 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Aug 2013 11:37:10 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <66338CC9-AA27-4912-92E9-A031A7CDDFBA@oracle.com> Date: Sun, 4 Aug 2013 14:37:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <009f01ce8229$6509e3a0$2f1daae0$@shockey.us> <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> <7A9C6940-5BC1-4A22-A4C8-85EF5495D4EC@brianrosen.net> <51E55F3E.8090205@dcrocker.net> <66338CC9-AA27-4912-92E9-A031A7CDDFBA@oracle.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: Re: [stir] Replay threat (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 18:37:18 -0000 I take it back - preventing true replay may be impossible, or at least = highly impractical. There're too many scenarios of legitimate call = spirals, even in the real world... all of which would appear to be = malicious replays but are actually legitimate and benign. So if we have = verifiers perform replay protection, then they're likely to detect = legitimate spirals as malicious replays, making the mechanism unusable. The safest thing, from a "will it work" perspective, might be to just = make the timestamp validity window very short. Like, say, a 9 minute = window - i.e., the verifier only accepts +/- 4.5 minutes. That still = lets the signer and verifier not synchronize clocks, and for the message = to traverse the path. For example in the worst case the signer can be 2 = minutes behind real time, and the verifier can be 2 minutes ahead of = real time, and it taking 30 seconds for the message to go between. That still won't prevent the call-forwarding cut-and-paste attack, but = then neither did true replay protection. -hadriel On Jul 16, 2013, at 2:17 PM, Hadriel Kaplan = wrote: >=20 > On Jul 16, 2013, at 10:57 AM, Dave Crocker wrote: >=20 >> Folks, >> Question to the group: >> There are a number of different styles of replay attack, with = different likelihoods and different effects (nature/degree of damage). >> What specific replay scenarios does the group deem it essential to = prevent and why? >> I've seen situations in which it was deemed acceptable to allow some = types of potential replay attacks, because the potential for its = occurrence and/or damage it would do were not a serious concern. >=20 > It depends on how you define "replay". In my personal opinion, the = threat of someone replaying the same SIP message against the same target = is virtually nil. It's not hard to prevent it I think, so I don't see a = reason not to prevent it. >=20 > We've already assumed the odds of a malicious MITM are very low. Or = to be more precise, we acknowledge there already are a ton of benign = MITM, and that if they wanted to be bad, caller-id authentication isn't = gonna prevent much. It's just closing a stateroom door on the Titanic. >=20 > We've acknowledged there are bad senders, but if they can get their = messages signed, they hardly need to replay the message with the same = signature. >=20 > We've acknowledged there are weak signers, but if they have the key to = sign messages, then they don't need to replay. >=20 > We've acknowledged (I think) that there are bad receivers. So we have = to prevent them from replaying a received message against a *different* = target. I think of that as more of a cut-and-paste attack than replay, = but I don't care what it's called. The point is that I can easily get a = bank to call me, and I should not be able to use their call request's = STIR info to call someone else and have that someone else believe the = bank is calling them. >=20 > Unfortunately, preventing that cut-and-paste attack is quite hard. = Mostly because it's hard to distinguish from a completely legitimate = call-forwarding case, and we have to support legitimate call-forwarding. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Sun Aug 4 12:27:44 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB3611E80D5 for ; Sun, 4 Aug 2013 12:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thPtuNpg9Gm4 for ; Sun, 4 Aug 2013 12:27:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D899D11E80D2 for ; Sun, 4 Aug 2013 12:27:37 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r74JRa7B030267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Aug 2013 19:27:37 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r74JRYbR019500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Aug 2013 19:27:35 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r74JRYaB001170; Sun, 4 Aug 2013 19:27:34 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Aug 2013 12:27:34 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Hadriel Kaplan X-Priority: 3 In-Reply-To: <7D8ECCC0A7324280A8C243CAAB895C93@Gateway> Date: Sun, 4 Aug 2013 15:27:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7D8ECCC0A7324280A8C243CAAB895C93@Gateway> To: "Anton Tveretin" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: stir@ietf.org Subject: Re: [stir] draft-kaplan-stir-ikes-out X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 19:27:44 -0000 On Aug 4, 2013, at 2:26 PM, "Anton Tveretin" = wrote: > Why should addresses be included into IKES? IMO that adds nothing but = extra work > for each validator. By "included" you mean included in the IKES-IF string encoded in the = message itself, e.g. the LIKES-IF SIP header? It's only included that = way in SIP and XMPP. It's included in them for two reasons: 1) To provide a quick match mechanism that can be performed before = having to retrieve a cert/pub-key and performing public key crypto. If = the canonical identities the verifier generates from the received = To/=46rom URIs don't match the ones in the LIKES-IF header, it knows = it's a failure and not to bother checking the signature. If they match, = then it goes and checks the signature. It's an optimization, but a = useful optimization, especially for call-forwarding cases to figure out = which destination identity to check the signature for. 2) To provide troubleshooting help. There's a concern that the = "canonicalization" process performed by the signer and verifier domains = might lead to different identities, resulting in a IKES verification = failure when it should instead succeed. By having the signer insert its = values into the new header, the admin of the receiving domain can figure = out if his canonicalization policies are wrong or not. > Chapter 11 (error): in DSS1, call termination is done with 3 messages > (DISCONNECT/RELEASE/RELEASE COMPLETE). In H.225.0 call control, just = one > (RELEASE COMPLETE). This error must be corrected. Yup, good catch - will do on next revision. > H.225.0 call control contains h323-uu-pdu, which coexists with = user-information, and thus it actually does not count to 131 bytes of = ISDN User-to-User IE. So I think it is possible to combine all ISDN = (ISUP, DSS1, H.225.0 CC). Yeah I knew H.225 could have its own - in fact one could just define new = ASN definitions for real/defined fields for the IKES information. See = below for more on that... > But, for H.323 it would be more critical to supply IKES in RAS (e.g. = ARQ) and H.501 messages IMO. Why is it critically important for RAS? > Yes, H.323 Forum might have a different opinion about H.323 dying. = Anyway, H.323 users deserve new features, practice shows that. Huh. I was under the impression is was on its last legs, even in video = conferencing. (but then I don't personally focus on the video = conferencing market, so I could be way off there) Regardless, I can = certainly update the draft for H.323 usage, and I will remove the = incorrect claim that its dead. Do you think it would be better to just remove H.323 from this draft = completely, and let the relevant parts for H.323 be worked out in = H-series docs by the ITU/whomever? That way we don't have to have any = new ASN definitions for the IKES information in this IKES draft, for = example. > And what about other networks, e.g. GSM? Right now the draft just says: "Other protocols wishing to support IKES = need to define their own mapping to the values defined in this = document." I didn't want to go and document one for every possible protocol in this = one IKES document - I figure if IKES gets deployed and used then other = protocol groups will do so in their own documentation, if they want to. = Like for example BICC, IAX, etc. All I wanted to do was prove it could = be done for other protocols, and in particular define how it could work = for SIP and SS7/ISUP. Even the XMPP usage might be better off in a = separate doc, in the IETF STOX working group or in an XSF XEP. -hadriel From richard@shockey.us Mon Aug 5 07:21:59 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B35621F9E0B for ; Mon, 5 Aug 2013 07:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.964 X-Spam-Level: X-Spam-Status: No, score=-100.964 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84aEb9KE3KxC for ; Mon, 5 Aug 2013 07:21:44 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id ADE6421F9EF4 for ; Mon, 5 Aug 2013 07:21:36 -0700 (PDT) Received: (qmail 22560 invoked by uid 0); 5 Aug 2013 14:21:12 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 5 Aug 2013 14:21:12 -0000 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:Date:Subject:To:From; bh=QjywUexshqQW6183lyYcRfGWDWx+A96DAw1oz9+LCKY=; b=cLKlagsSHGs47I+rxxWTztUSoESvBUCKzq7XUt662Q4F21Xzfxfp0tKawQkM4stPDGS5p86KqbsHtZfQzEVS9FqmxRfos3bSI0gbo+ecQ6OKSqRdPVQgty9+5Ia615iG; Received: from [71.114.100.16] (port=49966 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V6Leo-0003r9-J5 for stir@ietf.org; Mon, 05 Aug 2013 08:21:10 -0600 From: "Richard Shockey" To: Date: Mon, 5 Aug 2013 10:21:09 -0400 Message-ID: <00b801ce91e7$08774470$1965cd50$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01CE91C5.81672B10" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac6R5vvhYYKetz5yRrWBqLdDWvY1Ew== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Subject: [stir] FYI ... the UK Ofcom view of the problem statement. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:22:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B9_01CE91C5.81672B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://stakeholders.ofcom.org.uk/consultations/silent-calls/joint-action-pla n/ Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_000_00B9_01CE91C5.81672B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

http://stakeholders.ofcom.org.uk/consultations/silent-c= alls/joint-action-plan/

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: = rshockey101
http//www.sipforum.org

"Money is the answer, what is the question?" = tm

 

 

------=_NextPart_000_00B9_01CE91C5.81672B10-- From housley@vigilsec.com Mon Aug 5 12:32:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361FD21F9D9C for ; Mon, 5 Aug 2013 12:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.732 X-Spam-Level: X-Spam-Status: No, score=-102.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpNFScuKf2Wt for ; Mon, 5 Aug 2013 12:31:56 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1E121F9D4A for ; Mon, 5 Aug 2013 12:31:56 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 82FDCF24089 for ; Mon, 5 Aug 2013 15:32:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id oJvB6kGF9RG8 for ; Mon, 5 Aug 2013 15:31:12 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E30B2F24085 for ; Mon, 5 Aug 2013 15:32:34 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Aug 2013 15:31:51 -0400 Message-Id: <8BE71738-46A3-4462-AE74-6C1B9CD4389D@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [stir] IETF 87 STIR BOF Minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:32:01 -0000 http://www.ietf.org/proceedings/87/minutes/minutes-87-stir Thanks very much to Jean Mahoney and Olafur Gudmundsson for taking = notes. I assembled the minutes from these notes and then posted them. Please = send any corrections to the mail list. Russ From housley@vigilsec.com Mon Aug 5 12:44:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E5521F9E9E for ; Mon, 5 Aug 2013 12:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.725 X-Spam-Level: X-Spam-Status: No, score=-102.725 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxXT0xDvvWqx for ; Mon, 5 Aug 2013 12:44:19 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 036A021F9CBF for ; Mon, 5 Aug 2013 12:44:15 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id BF5FFF24032; Mon, 5 Aug 2013 15:45:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 0xJBltigWUCE; Mon, 5 Aug 2013 15:43:11 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 526B3F2402A; Mon, 5 Aug 2013 15:45:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> Date: Mon, 5 Aug 2013 15:44:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> To: Lucy Lynch , Steve Kent X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:44:24 -0000 Steve and Lucy: I have been thinking about your call for privacy document. The privacy document is fairly straight forward if you only consider the = use of a STIR credential in the in-band and an out-of-band mechanisms. = However, it gets much more complicated if one considers other potential = uses (and abuses) of this credential in other protocol environments. Do = you have any thoughts on this? Do you have proposed charter text? Russ On Jul 31, 2013, at 10:25 AM, Russ Housley wrote: > With the BOF behind us, I think there is one, and only one topic that = this mail list should be discussing. That is the charter text that is = ready for the IESG. >=20 > The pre-BOF charter text is here: = http://www.ietf.org/charter/charter-ietf-stir-00-00.txt >=20 > I will hold the pen on changes to the charter text. Some people = suggested changes during the BOF: >=20 > Preamble > - Remove "deployable" or change it to "rapidly deployable" > - Add "within call set up time" > - Add a discussion of a threat model > - Be clear that the "calling party" is identified by their telephone = number >=20 > Postamble > - Can something be said about alignment of incentives? >=20 > Privacy > - We need to do more than punt. >=20 > Please propose exact text for any of these topics. I prefer one = proposed change per message in a hope to more easily judge consensus. = To this end, I will start a thread on the inclusion of an out-of-band = mechanism. >=20 > Russ From housley@vigilsec.com Mon Aug 5 12:44:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52E321F968B for ; Mon, 5 Aug 2013 12:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.719 X-Spam-Level: X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4wgnpUtmdBb for ; Mon, 5 Aug 2013 12:44:42 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 844D121F857A for ; Mon, 5 Aug 2013 12:44:41 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 94B71F24032; Mon, 5 Aug 2013 15:45:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id sMHjLBnIRnLV; Mon, 5 Aug 2013 15:43:39 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1E575F2402A; Mon, 5 Aug 2013 15:45:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <51FA0753.6020600@bbn.com> Date: Mon, 5 Aug 2013 15:44:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <702EA082-43B7-490D-B909-00630A195CE4@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:44:49 -0000 Steve: I have been thinking about your call for a threat document and a privacy = document. The threat document is quite different if it cover an in-band mechanism = or both an in-band and an out-of-band mechanism. Do you have any = thoughts on this? Do you have proposed charter text? Russ On Aug 1, 2013, at 2:59 AM, Stephen Kent wrote: > Dave, >=20 > I refer you to the BGPSEC threat doc = (draft-ietf-sidr-bgpsec-threats-05), which is now > in the hands of the RTG ADs, as an example of what I have in mind. It = addresses a > fairly complex, global system, so I would not expect an analogous doc = for STIR > to be any longer. >=20 > Steve From housley@vigilsec.com Mon Aug 5 13:00:00 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E52E21F96B1 for ; Mon, 5 Aug 2013 13:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.713 X-Spam-Level: X-Spam-Status: No, score=-102.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVgOAl0nV893 for ; Mon, 5 Aug 2013 12:59:53 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3CD21F9425 for ; Mon, 5 Aug 2013 12:59:50 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id ADDACF24085 for ; Mon, 5 Aug 2013 16:00:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id OzL8G-jVeEtJ for ; Mon, 5 Aug 2013 15:58:19 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1A528F2402A for ; Mon, 5 Aug 2013 16:00:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <51F92CDD.4030306@bbn.com> Date: Mon, 5 Aug 2013 15:59:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Subject: [stir] Population Size X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:00:00 -0000 Steve Kent raised a question on the list about the population size. I = think we need to consider this question in the long-term. That is after = both the in-band and out-of-band mechanisms have been developed and = deployed. Steve said: =20 > I also think we need to have a discussion about the size of the = population > of calling parties who will have credentials, and the size of the = verifiers > in the system. This seemed to be the source of some disagreement = during the BoF, > and some proposals that might work well for small values of either (or = both) > of these parameters might not work well for very large values of these = parameters. So, I'd like to hear what people think, and what impact this has on the = charter text. Russ= From dhc@dcrocker.net Mon Aug 5 13:30:00 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2FC21F9C53 for ; Mon, 5 Aug 2013 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYP2JhOXWWrl for ; Mon, 5 Aug 2013 13:29:55 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBF321F9BA2 for ; Mon, 5 Aug 2013 13:29:53 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r75KToEi022044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 13:29:53 -0700 Message-ID: <52000B3B.3020407@dcrocker.net> Date: Mon, 05 Aug 2013 22:29:47 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 05 Aug 2013 13:29:53 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Population Size X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:30:00 -0000 On 8/5/2013 9:59 PM, Russ Housley wrote: > Steve Kent raised a question on the list about the population size. I think we need to consider this question in the long-term. That is after both the in-band and out-of-band mechanisms have been developed and deployed. > > Steve said: > >> I also think we need to have a discussion about the size of the population >> of calling parties who will have credentials, and the size of the verifiers >> in the system. This seemed to be the source of some disagreement during the BoF, >> and some proposals that might work well for small values of either (or both) >> of these parameters might not work well for very large values of these parameters. > > So, I'd like to hear what people think, and what impact this has on the charter text. Throughout list discussion, there has been a split view that sounded to me like a difference between "permitted" and "likely". Permitted has been cited as any calling handset, any calling enterprise and any calling provider, as well as any called provider, enterprise, or handset. As populations counts go, that's probably best described as "everyone". Likely has typically been described as calling and called providers, with perhaps some intermediaries, like SBCs. That's a somewhat smaller population. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From br@brianrosen.net Mon Aug 5 15:03:03 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF49E21F9D09 for ; Mon, 5 Aug 2013 15:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.31 X-Spam-Level: X-Spam-Status: No, score=-101.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGa2+cqEkw+x for ; Mon, 5 Aug 2013 15:02:59 -0700 (PDT) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id C045D21F9D6F for ; Mon, 5 Aug 2013 15:02:55 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md4so3896307pbc.16 for ; Mon, 05 Aug 2013 15:02:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=34HfYps7Q52uoV55EpvZIRlszau4K1qxp6kssxIFl0U=; b=prVLO8C+eQE8VBTM3IuVnqqfD7X6+hnourNWGBg88ii5QOOnnZVKU0jb3fgeeRkFp6 HJ0eTp2QQqNGnB6NxAryoZNpb9OPnmLSO4NeE4PScy1RGu+yauat8IZ1BKkZ6GwQrnMC Vr+wxLntTfWsWibm1b7uMsCpgXte43xZCugk3IrdFR2TCZb6tTF3xixEGJs3J4iULSS4 1v+LTc5T3lzRgH0Mlyhr5/cZBc+9IlDGwz2w8n1XgiY/2UZ0eg4DVBv5NGDL5NrWllSQ 0joVty7216qe2Pw+MhQHgqk660yfYLvsirpEWK0gI6xvQ+629Jme+Q6oE0V6ohuGnD9P Q4gQ== MIME-Version: 1.0 X-Received: by 10.66.231.100 with SMTP id tf4mr25225984pac.120.1375740175425; Mon, 05 Aug 2013 15:02:55 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Mon, 5 Aug 2013 15:02:55 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <52000B3B.3020407@dcrocker.net> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <52000B3B.3020407@dcrocker.net> Date: Mon, 5 Aug 2013 18:02:55 -0400 Message-ID: From: Brian Rosen To: "dcrocker@bbiw.net" Content-Type: multipart/alternative; boundary=047d7b111d2975b88e04e33a785c X-Gm-Message-State: ALoCoQmnWi5rDO2nIp26Z1Qn+NefN7h3cXQHrqmuGRGldqX9lZqaHHJVt1GtcyKWT24KuWI2dFI/ Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Population Size X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 22:03:03 -0000 --047d7b111d2975b88e04e33a785c Content-Type: text/plain; charset=ISO-8859-1 I would say, initial use of in band is service providers and perhaps large enterprise. Initial use of out of band is end devices. In band expands to smaller enterprises and eventually devices. Out of band may have some initial SP on-behalf-of use. Brian On Monday, August 5, 2013, Dave Crocker wrote: > On 8/5/2013 9:59 PM, Russ Housley wrote: > >> Steve Kent raised a question on the list about the population size. I >> think we need to consider this question in the long-term. That is after >> both the in-band and out-of-band mechanisms have been developed and >> deployed. >> >> Steve said: >> >> I also think we need to have a discussion about the size of the >>> population >>> of calling parties who will have credentials, and the size of the >>> verifiers >>> in the system. This seemed to be the source of some disagreement during >>> the BoF, >>> and some proposals that might work well for small values of either (or >>> both) >>> of these parameters might not work well for very large values of these >>> parameters. >>> >> >> So, I'd like to hear what people think, and what impact this has on the >> charter text. >> > > > Throughout list discussion, there has been a split view that sounded to me > like a difference between "permitted" and "likely". > > Permitted has been cited as any calling handset, any calling enterprise > and any calling provider, as well as any called provider, enterprise, or > handset. As populations counts go, that's probably best described as > "everyone". > > Likely has typically been described as calling and called providers, with > perhaps some intermediaries, like SBCs. That's a somewhat smaller > population. > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ______________________________**_________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/**listinfo/stir > --047d7b111d2975b88e04e33a785c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would say, initial use of in band is service providers and perhaps large = enterprise. =A0Initial use of out of band=A0is end devices. =A0In band expa= nds to smaller enterprises and eventually devices. =A0Out of band may have = some initial SP on-behalf-of use.

Brian

On Monday, August 5, 2013, Dave Cr= ocker wrote:
On 8/5/2013 9:59 PM, Russ H= ousley wrote:
Steve Kent raised a question on the list about the population size. =A0I th= ink we need to consider this question in the long-term. =A0That is after bo= th the in-band and out-of-band mechanisms have been developed and deployed.=

Steve said:

I also think we need to have a discussion about the size of the population<= br> of calling parties who will have credentials, and the size of the verifiers=
in the system. This seemed to be the source of some disagreement during the= BoF,
and some proposals that might work well for small values of either (or both= )
of these parameters might not work well for very large values of these para= meters.

So, I'd like to hear what people think, and what impact this has on the= charter text.


Throughout list discussion, there has been a split view that sounded to me = like a difference between "permitted" and "likely".

Permitted has been cited as any calling handset, any calling enterprise and= any calling provider, as well as any called provider, enterprise, or hands= et. =A0As populations counts go, that's probably best described as &quo= t;everyone".

Likely has typically been described as calling and called providers, with p= erhaps some intermediaries, like SBCs. =A0That's a somewhat smaller pop= ulation.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir
--047d7b111d2975b88e04e33a785c-- From dhc@dcrocker.net Mon Aug 5 15:29:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D0921F9048 for ; Mon, 5 Aug 2013 15:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVxy4iHxxkKp for ; Mon, 5 Aug 2013 15:29:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0136721F8ECA for ; Mon, 5 Aug 2013 15:29:51 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r75MTlCZ024287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 15:29:50 -0700 Message-ID: <52002759.1060601@dcrocker.net> Date: Tue, 06 Aug 2013 00:29:45 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <52000B3B.3020407@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 05 Aug 2013 15:29:50 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Population Size X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 22:29:58 -0000 On 8/6/2013 12:02 AM, Brian Rosen wrote: > I would say, initial use of in band is service providers and perhaps > large enterprise. Initial use of out of band is end devices. In band > expands to smaller enterprises and eventually devices. Out of band may > have some initial SP on-behalf-of use. A phrase like "initial use" invites the distinction between architecture and operation. That's why I made the 'permitted' vs. 'likely' distinction, so this issue is explicit. Is the architecture to be restricted only to providers? That seems to go against what has been said repeatedly on the list. If not restricted, then the "permitted' population appears to be essentially everybody. If there is a view that a restricted "initial" use has architectural import, while somehow permitting later expansion to the larger use case, what would that mean, specifically? And I thought that out of band was to be deferred for now. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Mon Aug 5 16:26:39 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C569921F9E26 for ; Mon, 5 Aug 2013 16:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1-89sEbLLoP for ; Mon, 5 Aug 2013 16:26:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5110221F91CE for ; Mon, 5 Aug 2013 16:26:33 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r75NQVDR013802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 23:26:32 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75NQQ16018424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 23:26:31 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75NQQTe018417; Mon, 5 Aug 2013 23:26:26 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2013 16:26:26 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 5 Aug 2013 19:26:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5BC9B1BA-1862-4505-B6A3-4992E9133EBD@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> To: Russ Housley X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List Subject: Re: [stir] Population Size X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 23:26:39 -0000 On Aug 5, 2013, at 3:59 PM, Russ Housley wrote: > Steve Kent raised a question on the list about the population size. I = think we need to consider this question in the long-term. That is after = both the in-band and out-of-band mechanisms have been developed and = deployed. >=20 > Steve said: =20 >=20 >> I also think we need to have a discussion about the size of the = population >> of calling parties who will have credentials, and the size of the = verifiers >> in the system. This seemed to be the source of some disagreement = during the BoF, >> and some proposals that might work well for small values of either = (or both) >> of these parameters might not work well for very large values of = these parameters. >=20 > So, I'd like to hear what people think, and what impact this has on = the charter text. Why would this have impact on the charter text? Brian gave some numbers before on the list: > There are several billion telephone numbers. I think most experts = believe there are more assigned numbers than people. =20 > There are 300-odd country codes > There are a few tens of thousands of service providers. If = enterprises get some form of credential, there are potentially high tens = of millions The likely target sizes, imo, if we think this will be world-wide: There are ~250 numbering authorities (cert CAs or PKI roots or whatever) Signers are only service providers and big Enterprises =3D ~50,000 max = signing organizations Verifiers are only service providers and big Enterprises =3D ~50,000 max = verifier organizations If you're asking about number of signing/verifying physical *systems*, = it's way more than 50k. If the doctor's office scenario occurs and is done by the phone itself, = there still aren't very many of those in practice, so it likely doesn't = matter much. It's possible that LTE mobile phones might do signing someday, in = certain roaming cases. It's possible they might do verifying as well. = If so, that would balloon things fast. I don't think that's likely to = happen though. It's possible that one or more countries might impose requirements that = Enterprises, or even LTE mobile phones, do both the signing and = verifying - or at least that they be allowed to. I can imagine a few = countries in Europe doing that, for example. If that happens, that = would balloon things to many millions, of course. The hard part with these things is we don't actually know the answer. = It's not hard to imagine new features one could enable were such a PKI = available, and if that happens, all bets are off. Some PSTN features = people thought would be super-popular fizzled out (e.g., ISDN video), = while other things that people thought would be minor became mega-hits = instead (e.g., SMS and number porting). -hadriel From eburger@standardstrack.com Mon Aug 5 17:03:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDA921F9EA2 for ; Mon, 5 Aug 2013 17:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.655 X-Spam-Level: X-Spam-Status: No, score=-99.655 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlKqbHrn8Jgj for ; Mon, 5 Aug 2013 17:02:46 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4637821F9E0D for ; Mon, 5 Aug 2013 17:02:41 -0700 (PDT) Received: from 64.sub-70-192-194.myvzw.com ([70.192.194.64]:5822 helo=[192.168.43.132]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V6UjX-0006gs-Hv for stir@ietf.org; Mon, 05 Aug 2013 17:02:39 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_02C68C85-EC70-4B88-98E0-D5410AB8B89A"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <1E587684-70A3-4782-AD7E-98169F3BB0B1@standardstrack.com> Date: Mon, 5 Aug 2013 16:37:00 -0400 To: IETF Mail List STIR Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-1.3 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 X-Source: X-Source-Args: X-Source-Dir: Subject: [stir] 15ms??? Where the heck did that come from? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 00:03:02 -0000 --Apple-Mail=_02C68C85-EC70-4B88-98E0-D5410AB8B89A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In the STIR BOF I mentioned that the time budget for *additional* = processing in the PSTN world would be on the order of 15ms. I need to = put a LOT of context around that statement. Twenty years ago (NOT TODAY), routing special PSTN calls, like free = phone or virtual networks, had a very tight time budget. There were both = government performance mandates and consumer drivers that ensured = carriers routed calls quickly. The big driver is callers might wait up = to 2500ms before they would abandon the call. At my company, the saying = we had was we never want one of our customers to say, "Why did I ever = switch from brand A?" as they hung up the phone and redialed. Given the latencies of local switches routing to long distance switches, = the latencies of breaking out call signaling to make a dozen or so data = base lookups, and returning the result so the call could be routed to = its destination, our total processing budget was 70ms. That was the days = of 30ms access time disks, so you can see the problem. So, on the one hand, in an IP environment we have a lot more time than = 15ms to do authentication steps, as we can do that work in parallel to = other routing logic. We are not restricted to adding on the exchanges = and algorithms in sequence to other routing processing. On the other hand, the statement that the budget is 10000ms is beyond = reality. Even in a World of Warcraft chat room, no one is going to wait = 10 seconds in the hope a connection request is successful. Granted, = mobile phones and early VoIP systems have trained users to have a little = more patience than 2500ms. However, to expect a user, in a PSTN = emulation environment, to hang on for more than 4000ms or 5000ms is = wishful thinking.= --Apple-Mail=_02C68C85-EC70-4B88-98E0-D5410AB8B89A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA1MjAzNzAwWjAjBgkqhkiG9w0BCQQxFgQU Sg8eCMJSOm2y1E2aCmMzH5xYxoswgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEArtDLlYyanMgGjTOxXz/TXLLm2+SqUABsh1iDkecgLy34QeJmoo22 QAiEOX/MzIR53XSP/f38dpRzWGacmsGIi86w29SUMSQjLtNscczmIpL04/VfepzC7Sv2rv4hRuhW cGXtsAo65ng+d7e+yyfT6I5pS92SfrTg1rSkU0j7Q9JnAtXR0ic3wz0ivE7FbVDQZnAcgdj+7ZIi 7ddbTwTpgxZuiwhU7zD7rrNiKavn1fxOR7P+zFy4U/60eIwBzLR4ljwDmiqWU9cHwN9YwSv5Esfr XBQ08QbxC4CObiukaJgGsPGkybXDK8uPo5xR0lFNMB9k3+psBwqwMJpsZ4PuOAAAAAAAAA== --Apple-Mail=_02C68C85-EC70-4B88-98E0-D5410AB8B89A-- From eburger@standardstrack.com Mon Aug 5 17:03:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA43921F9E9D for ; Mon, 5 Aug 2013 17:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.355 X-Spam-Level: X-Spam-Status: No, score=-99.355 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcI5OmrQ2Cfa for ; Mon, 5 Aug 2013 17:02:45 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4631B21F9DA0 for ; Mon, 5 Aug 2013 17:02:41 -0700 (PDT) Received: from 64.sub-70-192-194.myvzw.com ([70.192.194.64]:5822 helo=[192.168.43.132]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V6UjU-0006gs-Nz for stir@ietf.org; Mon, 05 Aug 2013 17:02:38 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_81604532-2171-4808-B0B5-30877589D21D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <95ABCB2E-EC89-421C-AA3F-09E50789A62B@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Mon, 5 Aug 2013 16:36:55 -0400 References: To: IETF STIR Mail List In-Reply-To: X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-1.3 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 X-Source: X-Source-Args: X-Source-Dir: Subject: [stir] What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 00:03:02 -0000 --Apple-Mail=_81604532-2171-4808-B0B5-30877589D21D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 What are the use cases and drivers? My understanding is there are two flaws with the current SIP identity = infrastructure. The first is the vast majority of 'calls' use E.164 = (telephone number) addressing. Thus we address them with = sip:+12345567890;user=3Dphone or tel:+1234567890 URI's. The current SIP = identity infrastructure does not handle anything but user@host = identities. Therefore, there is nothing we can do today to assert the = identity of a phone number in SIP. The second flaw in the identity infrastructure we have today is = asserted, authenticated identity does not survive passing through middle = boxes and B2BUA's. This comes from a mix of today's scheme being MITM = resistant by design and perhaps a bit overzealous in what is being = protected. The problem is real networks out there have a lot of B2BUA's = in them. Complicating matters, we have the extremely complex, real world user = rules that my device can forward calls from an authenticated sender and = that call is supposed to have the authenticated origin of the = authenticated sender (e.g., I am traveling and forward my desk phone to = my mobile phone). The problem here is it is trivial for a bad actor to = induce a good guy to call them so the bad actor can originate a call = with the authenticated good guy as the caller identity. Henning at the BOF gave a number of scenarios where the device needs to = lie about its identity. For example, a doctor on the golf course or at = home wants her outgoing caller identity to be that of her office, not = her home or personal phone. Legitimate enterprises regularly contract = with legitimate call centers to make outbound calls on the enterprise's = behalf. In this case, the enterprise want's their own caller identity to = pop up to their customer. They do not want to let the customer know they = have outsourced their call center to Panama. We then have the issue of deployment. Assuming we could get beyond the = impossible real-world scenarios that say "prevent a MITM attack, yet = design in a MITM attack" and "provide strong identity of the = origination, yet allow the origin to lie about its identity," we have = some other problems. If that were not enough! So, what do we have before us? We have one camp arguing for a = 'practical' solution that can address the robocalling problem. Since the = robocalling problem is primarily a PSTN problem, they are arguing for a = solution that is amenable to PSTN deployment. The PSTN handled this = problem pre-VoIP by noting which ISDN PRI circuit lied about the Caller = ID field. Since most networks were for somewhat trusted, one could trace = back to the bad actor. It was usually an enterprise doing something not = quite nice. My understanding is today carriers doing IP interconnect do not bother = to look at the Caller ID field. =46rom an inter exchange carrier's = (IXC's) perspective, there is no reason to. They are being paid by the = carrier that delivers the call to them. The IXC does not route based on = Caller ID, it routes based on dialed number. Note this is the identical = situation that a backbone provider has delivering spam. The backbone = provider has no reason to filter the mail, as they are being paid to = deliver it. Likewise, where the mail comes from does not factor into the = routing of the mail. Too bad for the poor individual or enterprise that = gets a massive bill for premium service numbers or the carrier that gets = hit with massive termination fees. So, to address today's PSTN problem, we want to be able to allow a = carrier to determine whom a call is really coming from. Then, once on = the PSTN, the carrier can use all of the legacy PSTN heuristics to deal = with Caller ID spoofing. That leads us to an in band solution, as the = gateway that bridges to the VoIP world would be able to authenticate the = caller's identity claim. This is relatively fast to deploy, as outbound = enterprises would want to do uptake of the technology so they do not get = blocked. The solution would be totally compatible with the existing = Caller ID infrastructure, as carrier network equipment can hack the = display number and name to their heart's content. Of course, any legacy Caller ID solution could be trivially hacked by = Caller ID spoofing, as the bad guy can just stuff the Caller ID fields = with something that looks legitimate. In this case, the carrier can = override the Caller ID markings if they do not pass authentication. This = also means that when grandma calls her kids, her kids will see a toxic = waste warning on their Caller ID screens. I do not think grandma will = appreciate that, but since I am not a regulator, that is not my problem. = Grandma is never going to upgrade her ATA. The good news is she will die = in a few decades from never talking with her grand kids, and the problem = of grandma not upgrading will just quietly pass away. Did I mention that IXC's have no incentive, or reason for that matter, = to look at the Caller ID fields? Just an observation. So, if in band identity authentication is hard, why not do the easy = thing and do out of band identity authentication? Let us again suspend = belief and assume we can solve the very hard (impossible?) problems of = simultaneously supporting no MITM attacks and must have MITM attacks as = well as simultaneously imposting not being able to lie about identity at = the same time that one must be able to lie about identity. It is easy to upgrade a few billion cell phones to support an out of = band scheme. Cell phones get cycled every two years or so, and = governments and manufacturers will be very eager to mandate strong = identity in the phone. There are lots of countries that require an = identity card, passport, or even just a credit card to buy a phone or = SIM card. Having the IETF endorse the practice of being able to = cryptographically tie an endpoint to a physical identity would be = nirvana for them. The problem here is grandma again. [Well, there is a = small problem of privacy, but I recall someone in the BOF saying = something akin to "screw privacy."] Most enterprises are running PBX = equipment that is a decade or so old with corresponding software loads. = Unless they are an outbound call center, they have no incentive to = upgrade. Likewise, grandma still only has an analog Caller ID box, maybe = connected to an ATA, but more likely connected to a DMS-10 with a VoIP = gateway hanging off the trunk side. She is never going to have an = endpoint that will do authentication of inbound caller identity. That = means for there to be any penetration, carriers are going to have to = install or upgrade their equipment to take their legacy Caller ID = origination or Caller ID delivery to be out of band aware. Another way = of putting it is they need to take out of band identity authentication = and turn it into in band identity authentication for it to be useful. = Sounds like an argument for in band=85 One last comment. I had a micro exchange with Hadriel about the IETF = punting on a PSTN-centric and totalitarian, police state-centric = solution and give it to a body that is used to that sort of engineering, = namely the ITU-T. The IETF can then focus on Internet-based, opt-in, = privacy preserving solutions. The counter argument was that instead of = SPIT, SWATing, and robocolls, look at how bad email spam mitigation is. = The assertion is an Internet-based approach would be much worse for the = user than a PSTN, government-driven approach. I just looked at my SpamSieve statistics. I get 99.5% accuracy. I see = 0.1% false positives (grandma going into spam jail) and 0.4% false = negatives (+234 still making it into my inbox). For email, that is = misrouting 5 messages per month. For voice, that would be something like = four or five mishandled calls PER YEAR. Sounds a lot better than the 2-3 spit calls I get per week. On Aug 1, 2013, at 5:49 AM, "DOLLY, MARTIN C" wrote: > I believe the FCC wants something will be deployed versus just placed = on the IETF RFC shelf, never to see a deployment light of day.... >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Peterson, Jon > Sent: Thursday, August 01, 2013 5:42 AM > To: Hadriel Kaplan; Richard Barnes > Cc: IETF STIR Mail List; Russ Housley; Dave Crocker > Subject: Re: [stir] Including out-of-band in the Charter >=20 >=20 > I think what's important are the points we discussed in the BoF: that > having both of these mechanisms under development in the same venue = lets > us reuse critical components of the architecture, avoid duplication of > effort, and scope what falls under the purview of one approach or the > other. That means that we pursue in-band mindful of the fact that > out-of-band is coming, and yes, when defining reusable components, we > ideally find designs for them that will accommodate both in-band and > out-of-band. >=20 > Jon Peterson > Neustar, inc. >=20 > On 8/1/13 11:29 AM, "Hadriel Kaplan" = wrote: >=20 >>=20 >> I think the concern, and I have it too, is that when one mixes oil = and >> water in a working group there are likely to be (1) differing views = of >> what's acceptable/not in terms of threats, deployment models and >> protocols, and operation/management of it, and (2) cases of = contention >> for the same resources, such as vying for time in WG meetings. >>=20 >> My interpretation of the charter is that if such things happen, then >> in-band wins; once in-band is submitted to IESG, out-of-band gets all = the >> time. For now we can talk about both in mailing list, and of course >> people can continue to work on out-of-band, discuss it in WG meetings = if >> there's time, etc. And when we work on our documents we have to keep >> out-of-band in mind... although if we do find there're some big >> differences or more documentation work required due to out-of-band, = then >> my assumption is we'd separate the out-of-band into separate docs to = work >> on later. >>=20 >> -hadriel >>=20 >>=20 >> On Aug 1, 2013, at 5:06 AM, Richard Barnes wrote: >>=20 >>> On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker = wrote: >>> On 8/1/2013 9:26 AM, Richard Barnes wrote: >>>=20 >>> That's why I didn't propose putting it in the charter :) Obviously, = we >>> will try to clarify this in the charter. >>>=20 >>>=20 >>> Color me even more confused than usual (and that's going some.) >>>=20 >>> Advice from the cognizant AD about what technical issues to = "consider" >>> when working is usually treated as definitive direction, absent an >>> overriding appeal (which isn't ever requested, nevermind sustained.) >>>=20 >>> That's an overstatement. To quote the Tao: >>> "Many people look at the ADs as somewhat godlike creatures ... = However, >>> most ADs are nearly indistinguishable from mere mortals and rarely = speak >>> from mountaintops." >>>=20 >>> More to the point, I didn't mean it that way. That's why, for = example, >>> I said "I would encourage..." and not "Thou shalt..." I consider = the >>> charter to be the real commitment. >>>=20 >>>=20 >>>=20 >>> Perhaps you could respond to the substance of the concern I raised = in >>> my previous note? >>>=20 >>> I take this to mean your concern that my "keep in mind" suggestion >>> would encourage people to work on things in parallel rather than >>> sequence. >>>=20 >>> The intent is actually the opposite, to help people get interested = in >>> out-of-band more engaged in in-band. If the in-band solution = requires >>> parts (A,B,C) and out-of-band requires (A,B,D), then people = interested >>> in out-of-band should be interested in A and B, and not just checked = out >>> of the WG until in-band is done. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>> d/ >>>=20 >>>=20 >>> --=20 >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_81604532-2171-4808-B0B5-30877589D21D 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 iQIcBAEBAgAGBQJSAAznAAoJEORoZaSQsc1IGewQAMJz9JfJO8tJ3EN/+WBd7XdZ 2gILjg7xVW/Mkumm1HQ0WLCrhfYWohI2SZBb3UqOFzR22QCDEEF5z4712ZtERbsl kvlqlD0t01P2rBoTW8DnoF/AK93mrvDGx0xGLD6pPS4fhnf2iTiVrz8Rgsa2LjwR Qz75Sdi/5Ht14MTV5Mz8cSEOXZ/8j2aui6o62jnd/G8v18ORdZl2tGM/zXIIJb7s UqogDEpie6qM0sYXkiWgoYF1Pr8aWtd+YnSMs+ZPWr4tWeW1QMgZbLwB/sllPxk1 q3hchEGKEsDDPlYRT8+FJXNG4GUAbzQGQzKlRoy2pbnDnaweYhqsHtvnBBg+QOH3 LjaIOnR3oqRq7++bew/bGkgtfx/8ROiHLaUjOBPfG3lfYAjCCbNQc/aHWq9Y1J/p cQ4doN1SbH8QvifEj+lDybkq7t9ZZGACYKHWgtsQ82zou2zC5jT0DdQcePrwuDzu +t3CKlR+DCAqBf86djWM9HCzeqKusIpOqySyG4jA09z/NQY6JEod8GHaEcNOX4cb hKaoN1EFJKhrJOBfh/nE/1k74kXY98dgSrnoWosVUP92PtwF+6i+fnwwEPzgn63L gLYQpL/frXqldAyBNHH2lcz+qHKOMhBTJi1GOOM8UhKcLpxbtHHIiVEeuRWrgCip O2o+ypjB+Ox0W8KEkpAG =eF4n -----END PGP SIGNATURE----- --Apple-Mail=_81604532-2171-4808-B0B5-30877589D21D-- From eburger@standardstrack.com Mon Aug 5 17:03:06 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B5A21F9E27 for ; Mon, 5 Aug 2013 17:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.105 X-Spam-Level: X-Spam-Status: No, score=-101.105 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyV9yVTMfXVZ for ; Mon, 5 Aug 2013 17:03:01 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 463F221F9E26 for ; Mon, 5 Aug 2013 17:02:41 -0700 (PDT) Received: from 64.sub-70-192-194.myvzw.com ([70.192.194.64]:5822 helo=[192.168.43.132]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V6UjR-0006gs-Dw; Mon, 05 Aug 2013 17:02:33 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_B143892E-B199-4A73-B2BA-52898EAFB8EB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric Burger In-Reply-To: <51F93BB3.6090706@dcrocker.net> Date: Mon, 5 Aug 2013 16:36:40 -0400 Message-Id: <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-1.3 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 X-Source: X-Source-Args: X-Source-Dir: Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 00:03:06 -0000 --Apple-Mail=_B143892E-B199-4A73-B2BA-52898EAFB8EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree we are not looking at a national security private network = analysis. However, we are talking about the potential end of any privacy = or anonymity for ANY Internet application, more especially Internet = multimedia application. That needs to have a level of analysis that goes = beyond either "hopelessly broken" or "don't worry about it." On Jul 31, 2013, at 12:30 PM, Dave Crocker wrote: > On 7/31/2013 5:27 PM, Stephen Kent wrote: >> As I mentioned at the mic, I'd like to see both a threat model and a >> privacy analysis as deliverables early in this process. >=20 > +1 >=20 > The only caveat I'll raise is based on a 'scoping' problem that = happened for the threats exercise when the DKIM wg was being formed. = What we were initially asked for was a rather basic consideration of = threats, to formulate some summary, pragmatic statements. >=20 > Within a few days, a few IETF security folk -- I don't recall Herr = Kent's position on this -- attempted to turn this into a detailed = exercise at a level of detail I was told would have been appropriate to = a military security system. Calling that onerous would entirely miss = how unrealistic it would have been to attempt. >=20 > I thought the original request quite appropriate, since it would get = everyone on the same page about some essential motivations and goals for = the effort. The result was a 25-page RFC.[1] I've never been clear = whether it was more work than reasonable, too little, or just right. >=20 > So I suggest some care in formulating these requirements, to keep it = useful, quick and short. >=20 >=20 >> I also think we need to have a discussion about the size of the >> population of calling parties who will have credentials, and the size >> of the verifiers in the system. >=20 > +1 >=20 >=20 > d/ >=20 >=20 > [1] http://www.ietf.org/rfc/rfc4686.txt >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_B143892E-B199-4A73-B2BA-52898EAFB8EB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA1MjAzNjQxWjAjBgkqhkiG9w0BCQQxFgQU 3Sff8OoWfsIleUpbQV1Xk2EJLyEwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAbbQ3ArYvAG0RT5Ktpt5tIoIYAnA8mPtM419TUlWhLuu47snisWe/ VjGGg9Rfb0iUZyQwUOp/BF7+Ta/00aqw5MVMOw9+fQfe7dOUxhSBwdrEmVpC1TOAeADNYCN4v8pX LtAhI/lpjOh3rZdFBf8dVxvO+Lhap9xHQWR4N+1zoA0T0RCjtcaXzEjmkjoqpVtS3QIp78I6cgOa 5HFyXqzPXo5XOFVs8Wy3x+UhOma30qNmVpdo1EdwCqaCIkGCQKtu/udrDHvPFBJt67eY+W7Hs1M5 tQG2XZME7VgIqzlx8HbFH5v/WV4+8dlZcuKFFWu0itvhyXglTZ/TwXC2Z1fPBwAAAAAAAA== --Apple-Mail=_B143892E-B199-4A73-B2BA-52898EAFB8EB-- From eburger@standardstrack.com Mon Aug 5 17:03:10 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09E921F9F6C for ; Mon, 5 Aug 2013 17:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.659 X-Spam-Level: X-Spam-Status: No, score=-100.659 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_20=-0.74, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nULQgRHzmhLv for ; Mon, 5 Aug 2013 17:03:06 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id B0CD921F9D9B for ; Mon, 5 Aug 2013 17:02:48 -0700 (PDT) Received: from 64.sub-70-192-194.myvzw.com ([70.192.194.64]:5822 helo=[192.168.43.132]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V6UjY-0006gs-JA; Mon, 05 Aug 2013 17:02:43 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_3F316381-95C9-4487-B609-07E40160DEA3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric Burger In-Reply-To: <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> Date: Mon, 5 Aug 2013 16:37:27 -0400 Message-Id: <15A0CCE6-F63E-4C8A-B10C-FF0B11C87EB9@standardstrack.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-1.3 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 X-Source: X-Source-Args: X-Source-Dir: Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 00:03:11 -0000 --Apple-Mail=_3F316381-95C9-4487-B609-07E40160DEA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If the IAB wants to look into it or if the IAB would like to ask ISOC to = look into it, I am sure the IAB will look into it or ask ISOC to look = into it. In the shameless self promotion department, I know a professor of = government who is a real lawyer (i.e., NOT me) who can do the work, for = a small fee. On Jul 31, 2013, at 12:38 PM, Richard Shockey = wrote: >=20 > I agree though as Lucy Lynch pointed out in calling out attention to = the > privacy problem there may be an interesting dimension to this. When = does the > right to privacy trump the right to be anonymous? We are confronted = with a > situation where a genuine perceived need for anonymous communications > identity for some has become a shield for criminal behavior. =20 >=20 > The other issue maybe ISOC can help us with this problem is we still = don't > have an idea of the scope of the problem beyond North America. Other > jurisdictions handle this differently and this is a perfect = opportunity to > encourage national regulators to engage with the IETF/ISOC in = investigating > these problems. >=20 > I would argue that what we are seeing in North America is the "Canary = in the > Coal Mine". =20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Stephen Kent > Sent: Wednesday, July 31, 2013 11:27 AM > To: stir@ietf.org > Subject: Re: [stir] Moving from BOF to Charter >=20 > Russ, >=20 > As I mentioned at the mic, I'd like to see both a threat model and a = privacy > analysis as deliverables early in this process. >=20 > I also think we need to have a discussion about the size of the = population > of calling parties who will have credentials, and the size of the = verifiers > in the system. This seemed to be the source of some disagreement = during the > BoF, and some proposals that might work well for small values of = either (or > both) of these parameters might not work well for very large values of = these > parameters. >=20 > The texts says: >=20 > As its first work item, the working group will specify a SIP = header-based > authorization mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, >=20 > Should the "authorization" be "authentication" above. I agree with the = use > of "authorized" in the latter part of the sentence. >=20 > later, the text says: >=20 > After completing the in-band mechanism, the working group will = consider > session establishment where there are one or more non-SIP hops, most = likely > using an out-of-band authorization mechanism. >=20 > Did you mean authorization or authentication here? >=20 > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_3F316381-95C9-4487-B609-07E40160DEA3 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 iQIcBAEBAgAGBQJSAA0HAAoJEORoZaSQsc1IDgUP/1/FA0k3sZ0suQUMGFyIGUmW peTX/cUJogzDRYb/ro32ntv24kmkPz48hUQmzAi2OTMYUg6O/PYq8i2eFGoH4enT WGMEx2VfdrB2DC2Hr2pTeF+aOTRoRUzb6JcuM0Lwpxsh2OXwDOI0Mh8BYKRauBvY R9X0fkjXdS0Wigv1Jth08nnyWjtHC5SGM+X1nigHz5ojxHkv3zoXdUYTYH6VsQq+ H6Rd1/w49bNylhs2pfyRi91OpusUg8EKQzX3CByyghJaCS2w35W7ovQpqOa+zB6f jkBDAweKvydcIY4WmjGS4+7sREcCVhzgrh5+0QqRv4MyKXgEWdoJNtMp9xdNGVls KUb1RfbTxxnxmuOqp009N4+6Oe0vIEztFB/iZUqg1gVgLkFKeOr4tMjdvXgcpP1H ZEKsJuT8SWXVjIOCwYn9scad79ru4GVIPxcEBEa59I5nAzUeGbeBDmCzJZLbYB9W 3SkZ7zt+r82Kc1CSx45tSI664LVTOS0qwy5t71ZhTAB/noVZqFsobwoPAyyorbMH HZjrkyNzDx7m+JaTJDmLgZwJVGYlUxZuaR0P0JLFWmeLeEp7Rz7E91+STQ51Xrn8 yV4LUL/d1m9NEh/vTxDRjbe8vmBfzc7MbeS1sPTUfpO0QPiGYt4YyxqEoy3T949P u93b9D+MlSMGvXuqA05B =pBUs -----END PGP SIGNATURE----- --Apple-Mail=_3F316381-95C9-4487-B609-07E40160DEA3-- From michael.hammer@yaanatech.com Mon Aug 5 17:28:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2428421F9EED for ; Mon, 5 Aug 2013 17:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id capD3FSXLFT3 for ; Mon, 5 Aug 2013 17:28:46 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1421F9EE9 for ; Mon, 5 Aug 2013 17:28:41 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 5 Aug 2013 17:28:35 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "housley@vigilsec.com" Thread-Topic: [stir] Population Size Thread-Index: AQHOkhZk4rEfXi+Lk06n64JlTN43tZmHt5IA//+breA= Date: Tue, 6 Aug 2013 00:28:33 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC23D2D@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <5BC9B1BA-1862-4505-B6A3-4992E9133EBD@oracle.com> In-Reply-To: <5BC9B1BA-1862-4505-B6A3-4992E9133EBD@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.219] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0519_01CE921A.5AB7E810" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Population Size X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 00:28:50 -0000 ------=_NextPart_000_0519_01CE921A.5AB7E810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I vote for a gazillion. We could just say it needs to operate at Internet scale and move on. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, August 05, 2013 7:26 PM To: Russ Housley Cc: IETF STIR Mail List Subject: Re: [stir] Population Size On Aug 5, 2013, at 3:59 PM, Russ Housley wrote: > Steve Kent raised a question on the list about the population size. I think we need to consider this question in the long-term. That is after both the in-band and out-of-band mechanisms have been developed and deployed. > > Steve said: > >> I also think we need to have a discussion about the size of the >> population of calling parties who will have credentials, and the size >> of the verifiers in the system. This seemed to be the source of some >> disagreement during the BoF, and some proposals that might work well >> for small values of either (or both) of these parameters might not work well for very large values of these parameters. > > So, I'd like to hear what people think, and what impact this has on the charter text. Why would this have impact on the charter text? Brian gave some numbers before on the list: > There are several billion telephone numbers. I think most experts believe there are more assigned numbers than people. > There are 300-odd country codes > There are a few tens of thousands of service providers. If > enterprises get some form of credential, there are potentially high > tens of millions The likely target sizes, imo, if we think this will be world-wide: There are ~250 numbering authorities (cert CAs or PKI roots or whatever) Signers are only service providers and big Enterprises = ~50,000 max signing organizations Verifiers are only service providers and big Enterprises = ~50,000 max verifier organizations If you're asking about number of signing/verifying physical *systems*, it's way more than 50k. If the doctor's office scenario occurs and is done by the phone itself, there still aren't very many of those in practice, so it likely doesn't matter much. It's possible that LTE mobile phones might do signing someday, in certain roaming cases. It's possible they might do verifying as well. If so, that would balloon things fast. I don't think that's likely to happen though. It's possible that one or more countries might impose requirements that Enterprises, or even LTE mobile phones, do both the signing and verifying - or at least that they be allowed to. I can imagine a few countries in Europe doing that, for example. If that happens, that would balloon things to many millions, of course. The hard part with these things is we don't actually know the answer. It's not hard to imagine new features one could enable were such a PKI available, and if that happens, all bets are off. Some PSTN features people thought would be super-popular fizzled out (e.g., ISDN video), while other things that people thought would be minor became mega-hits instead (e.g., SMS and number porting). -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0519_01CE921A.5AB7E810 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw NjAwMjgzMlowIwYJKoZIhvcNAQkEMRYEFItGMfUdvjtmumSt3sBKC07q+/RSMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAfP26z0Rtu19OEqeZo5fm+ypoqT15md2myPCdFom/ bH/hVZkNhQ/8JfwTQvCViOFX2y92UjhYuRhBz/pNUl8d0xoAq4uAue2S4EwaI02cfpePcA4cUYWz 7OGJTKCRr7Tz6RkvS+oOm7GMyGFYxci4m25nS+M6c/IRNKTGLkik2Fs5FaB1nofh2GsyQj+o9lie UppE316a2urEVGFAD8iF1kNXI0aG0FVcOcGeCMgBr0O7cWXi07xAF8ud0tsBzgRd1cUD2DuwmAk0 WsDo1lEGU2LBL9uWOpI+Lva7qdZg8S3r20X13tJY/Rr6p7t1wWLpVCT+VEFD9Og71MQZ88naxQAA AAAAAA== ------=_NextPart_000_0519_01CE921A.5AB7E810-- From philippe.fouquart@orange.com Tue Aug 6 02:41:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFDE21F99F8 for ; Tue, 6 Aug 2013 02:41:45 -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=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M07yawVLoggt for ; Tue, 6 Aug 2013 02:41:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 098CB21F8F4A for ; Tue, 6 Aug 2013 02:41:40 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A242732539C; Tue, 6 Aug 2013 11:41:39 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 842DC4C108; Tue, 6 Aug 2013 11:41:39 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 11:41:39 +0200 From: To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] IETF 87 STIR BOF Minutes Thread-Index: AQHOkhJ3Q89rev+4nEyMJzg1HFHb65mH7MoQ Date: Tue, 6 Aug 2013 09:41:39 +0000 Message-ID: <29522_1375782099_5200C4D3_29522_3064_1_B5939C6860701C49AA39C5DA5189448B0B76DE@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <8BE71738-46A3-4462-AE74-6C1B9CD4389D@vigilsec.com> In-Reply-To: <8BE71738-46A3-4462-AE74-6C1B9CD4389D@vigilsec.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.6.84301 Subject: Re: [stir] IETF 87 STIR BOF Minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 09:41:45 -0000 Thanks to the note takers.=20 Under slide 23. (search on " if the numbering policies are legal or not") Actually national numbering policies per se are always "legal", by construc= tion. I think my intervention was more along the lines of "There are variat= ions, and the exact nature of the problem may depend on the national number= ing policies and what they permit, or consider "legal" or not, eg suballoca= tion." If the former phrase could be changed into the latter, it'd probably= be clearer. Thanks. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Monday, August 05, 2013 9:32 PM To: IETF STIR Mail List Subject: [stir] IETF 87 STIR BOF Minutes http://www.ietf.org/proceedings/87/minutes/minutes-87-stir Thanks very much to Jean Mahoney and Olafur Gudmundsson for taking notes. I assembled the minutes from these notes and then posted them. Please send= any corrections to the mail list. Russ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ 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 hadriel.kaplan@oracle.com Tue Aug 6 03:50:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2903021F92A5 for ; Tue, 6 Aug 2013 03:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekD5AdPjyl1h for ; Tue, 6 Aug 2013 03:50:41 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1E721F9957 for ; Tue, 6 Aug 2013 03:50:41 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76AoZfP010187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 10:50:36 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76AoXg6025894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 10:50:33 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76AoXw1018954; Tue, 6 Aug 2013 10:50:33 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 03:50:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> Date: Tue, 6 Aug 2013 06:50:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: stir@ietf.org, dcrocker@bbiw.net Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 10:50:48 -0000 On Aug 5, 2013, at 4:36 PM, Eric Burger = wrote: > I agree we are not looking at a national security private network = analysis. However, we are talking about the potential end of any privacy = or anonymity for ANY Internet application, more especially Internet = multimedia application. How so? Obviously we could theoretically create some mechanism that = took all call information from/to everyone and posted it to wikileaks or=20= whatever, but I don't think we're that stupid. (nor do I think it would = get published by the IETF, nor would anyone use it if we did) No one is proposing, for example, that anonymous calls no longer remain = anonymous. Nor that one can't make anonymous calls. Your statement seems a bit alarmist. -hadriel From hadriel.kaplan@oracle.com Tue Aug 6 04:38:12 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA1E21F9DC6 for ; Tue, 6 Aug 2013 04:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkjxmuw2PiDX for ; Tue, 6 Aug 2013 04:38:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id ED2BD21F9DA1 for ; Tue, 6 Aug 2013 04:38:06 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76Bc5Vh005171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 11:38:06 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76Bc2e4027502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 11:38:04 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76Bc22O027483; Tue, 6 Aug 2013 11:38:02 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 04:38:02 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <1E587684-70A3-4782-AD7E-98169F3BB0B1@standardstrack.com> Date: Tue, 6 Aug 2013 07:38:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E587684-70A3-4782-AD7E-98169F3BB0B1@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: IETF Mail List STIR Subject: Re: [stir] 15ms??? Where the heck did that come from? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:38:12 -0000 Agreed - the budget is not as low as 15ms, but nowhere near as high as 4 = seconds. It's actually quite hard to come up with a hard limit though, = as a general requirement for STIR for all scenarios. Generally I just = think of it as: "as low as we can possibly make it". Some people have been talking about it from the perspective of = acceptable post-dial-delay (PDD), but I think that's the wrong way to = think about it - because STIR is adding additional time to whatever is = already deployed today. So the real question is how much *additional* = time do we think STIR can introduce, without being a barrier to = adoption. That's why for me the topic boils down to "make it = super-frigging' fast". As an equipment vendor, for example, my employer gets requirements for = SIP message processing in the order of single-digit milliseconds if = there's no external DB query. Even when we query external databases, = we're sometimes required to stop waiting for a DB answer after only tens = of milliseconds (or less than 100ms), and forward the call on = regardless. This may be because some wholesale carrier SLAs are = measured on post-dial-delay; or it may just be because so many systems = are involved in call processing, and the cumulative delay would become = so untenable, that the carriers decide to require a consistent common = max value for all systems. I don't know for sure. Either way, carriers = are very sensitive to call delays. [As an aside for those who care: according to ITU E.721, the mean delay = budget for end-to-end PDD is 3 seconds for local calls, 5 seconds for = national long-distance, and 8 seconds for international. But that spec = is really conservative and is based on phone-to-phone time. For the SS7 = network, a different spec (E.723) gives the end-to-end PDD across the = SS7 system as 0.9 seconds for local calls, 2.3 seconds for = long-distance, and 4 seconds for international. Mobile phones/networks = have a different set of values, I believe. But again, looking at these = numbers provides a false sense of time budget for STIR.] -hadriel On Aug 5, 2013, at 4:37 PM, Eric Burger = wrote: > In the STIR BOF I mentioned that the time budget for *additional* = processing in the PSTN world would be on the order of 15ms. I need to = put a LOT of context around that statement. >=20 > Twenty years ago (NOT TODAY), routing special PSTN calls, like free = phone or virtual networks, had a very tight time budget. There were both = government performance mandates and consumer drivers that ensured = carriers routed calls quickly. The big driver is callers might wait up = to 2500ms before they would abandon the call. At my company, the saying = we had was we never want one of our customers to say, "Why did I ever = switch from brand A?" as they hung up the phone and redialed. >=20 > Given the latencies of local switches routing to long distance = switches, the latencies of breaking out call signaling to make a dozen = or so data base lookups, and returning the result so the call could be = routed to its destination, our total processing budget was 70ms. That = was the days of 30ms access time disks, so you can see the problem. >=20 > So, on the one hand, in an IP environment we have a lot more time than = 15ms to do authentication steps, as we can do that work in parallel to = other routing logic. We are not restricted to adding on the exchanges = and algorithms in sequence to other routing processing. >=20 > On the other hand, the statement that the budget is 10000ms is beyond = reality. Even in a World of Warcraft chat room, no one is going to wait = 10 seconds in the hope a connection request is successful. Granted, = mobile phones and early VoIP systems have trained users to have a little = more patience than 2500ms. However, to expect a user, in a PSTN = emulation environment, to hang on for more than 4000ms or 5000ms is = wishful thinking._______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Tue Aug 6 06:27:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C7F21F9346 for ; Tue, 6 Aug 2013 06:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzscstzhj2jo for ; Tue, 6 Aug 2013 06:26:57 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4069721F9371 for ; Tue, 6 Aug 2013 06:26:57 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 6 Aug 2013 06:26:56 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "eburger@standardstrack.com" Thread-Topic: [stir] 15ms??? Where the heck did that come from? Thread-Index: AQHOkjhXzr01Ko650UCyIudev5rbRZmIg7YA//+oyeA= Date: Tue, 6 Aug 2013 13:26:55 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC23F19@EX2K10MB1.corp.yaanatech.com> References: <1E587684-70A3-4782-AD7E-98169F3BB0B1@standardstrack.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.237] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002C_01CE9287.16AD9D00" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 15ms??? Where the heck did that come from? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:27:01 -0000 ------=_NextPart_000_002C_01CE9287.16AD9D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't think those are false numbers, those are what people are used to. Technology moved forward, we don't want to start doing worse and worse. We also need to avoid having any cumulative delay across multiple networks. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, August 06, 2013 7:38 AM To: Eric Burger Cc: IETF Mail List STIR Subject: Re: [stir] 15ms??? Where the heck did that come from? Agreed - the budget is not as low as 15ms, but nowhere near as high as 4 seconds. It's actually quite hard to come up with a hard limit though, as a general requirement for STIR for all scenarios. Generally I just think of it as: "as low as we can possibly make it". Some people have been talking about it from the perspective of acceptable post-dial-delay (PDD), but I think that's the wrong way to think about it - because STIR is adding additional time to whatever is already deployed today. So the real question is how much *additional* time do we think STIR can introduce, without being a barrier to adoption. That's why for me the topic boils down to "make it super-frigging' fast". As an equipment vendor, for example, my employer gets requirements for SIP message processing in the order of single-digit milliseconds if there's no external DB query. Even when we query external databases, we're sometimes required to stop waiting for a DB answer after only tens of milliseconds (or less than 100ms), and forward the call on regardless. This may be because some wholesale carrier SLAs are measured on post-dial-delay; or it may just be because so many systems are involved in call processing, and the cumulative delay would become so untenable, that the carriers decide to require a consistent common max value for all systems. I don't know for sure. Either way, carriers are very sensitive to call delays. [As an aside for those who care: according to ITU E.721, the mean delay budget for end-to-end PDD is 3 seconds for local calls, 5 seconds for national long-distance, and 8 seconds for international. But that spec is really conservative and is based on phone-to-phone time. For the SS7 network, a different spec (E.723) gives the end-to-end PDD across the SS7 system as 0.9 seconds for local calls, 2.3 seconds for long-distance, and 4 seconds for international. Mobile phones/networks have a different set of values, I believe. But again, looking at these numbers provides a false sense of time budget for STIR.] -hadriel On Aug 5, 2013, at 4:37 PM, Eric Burger wrote: > In the STIR BOF I mentioned that the time budget for *additional* processing in the PSTN world would be on the order of 15ms. I need to put a LOT of context around that statement. > > Twenty years ago (NOT TODAY), routing special PSTN calls, like free phone or virtual networks, had a very tight time budget. There were both government performance mandates and consumer drivers that ensured carriers routed calls quickly. The big driver is callers might wait up to 2500ms before they would abandon the call. At my company, the saying we had was we never want one of our customers to say, "Why did I ever switch from brand A?" as they hung up the phone and redialed. > > Given the latencies of local switches routing to long distance switches, the latencies of breaking out call signaling to make a dozen or so data base lookups, and returning the result so the call could be routed to its destination, our total processing budget was 70ms. That was the days of 30ms access time disks, so you can see the problem. > > So, on the one hand, in an IP environment we have a lot more time than 15ms to do authentication steps, as we can do that work in parallel to other routing logic. We are not restricted to adding on the exchanges and algorithms in sequence to other routing processing. > > On the other hand, the statement that the budget is 10000ms is beyond reality. Even in a World of Warcraft chat room, no one is going to wait 10 seconds in the hope a connection request is successful. Granted, mobile phones and early VoIP systems have trained users to have a little more patience than 2500ms. However, to expect a user, in a PSTN emulation environment, to hang on for more than 4000ms or 5000ms is wishful thinking._______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_002C_01CE9287.16AD9D00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw NjEzMjY1M1owIwYJKoZIhvcNAQkEMRYEFCfReJH7LNxltAVj7+CBHkzopFqTMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEATx2wuouo0bITqdTEFyyjgnzes7eYBsVeBQa2a37U sJLPJADG5eUMrzr/3zJCzojm2MoLHwnVmIKEcMBBEXqVHlF5FNLeNc6ATie8VkDyVWRag7If8Q3/ M7fjImtMzeonpQHTwIxRyYSoeBQ8IZ2kC6c6eVNswdVE6CO43M8wVpjztZvlTEN01FTKZRpI+T5c fSZ9ZXxl6sOmxgPaS7OcZd7EVtLeS4WX9+hcdKeNBtkQCNVgj6Fk/dZiQR9E3uXeCnoxdhdlTkPU k5pmhr9Lh0gRpU9BDyhfAj3v3Dj2xiBjg17CKapvqYCjA11clmCZRTXoGiUcI7RQtLAOgKw3FwAA AAAAAA== ------=_NextPart_000_002C_01CE9287.16AD9D00-- From hadriel.kaplan@oracle.com Tue Aug 6 06:47:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D3321F9DCE for ; Tue, 6 Aug 2013 06:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.27 X-Spam-Level: X-Spam-Status: No, score=-5.27 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvROYKVMiEBE for ; Tue, 6 Aug 2013 06:47:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 925BC21F9EF6 for ; Tue, 6 Aug 2013 06:47:27 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76DlPak026957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 13:47:26 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76DlJaF029157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 13:47:20 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76DlJgo019084; Tue, 6 Aug 2013 13:47:19 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 06:47:19 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <95ABCB2E-EC89-421C-AA3F-09E50789A62B@standardstrack.com> Date: Tue, 6 Aug 2013 09:47:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E3C98D1-3BED-4A7E-A5B1-5C6197706845@oracle.com> References: <95ABCB2E-EC89-421C-AA3F-09E50789A62B@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: IETF STIR Mail List Subject: Re: [stir] What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:47:50 -0000 [You sent a long email, so responding will be a long email...] General comment: Many of the points you raise, and your arguments for/against, have been = raised before and answered - and answered sufficiently such that there = appears to be continuing interest in solving it per the current charter, = here in the IETF. Given the number of emails on this mailing list, it's = not a surprise that we get the same questions again and again, because = it's not reasonable to expect people to read all the emails from day 1. = I think we're going to need to write up a FAQ somewhere - either in a = draft or on a wiki somewhere, so we can point people to it and say = "RTFM". Regarding motivations of carriers: Many of us wouldn't be wasting our time with STIR if we didn't think = carriers had motivation for deploying it, including IXCs. In the most = pessimistic view, the motivation might purely be due to government = mandates. Governments do in fact issue and enforce requirements on = telephone-service carriers, including IXCs, as you well know. I happen = to take a more optimistic view, and think the carriers have other = motivations, but it's not necessary to believe that. Regarding what STIR is about: You seem to be under the belief that STIR is about preventing "spam", by = which I think you mean telemarketing calls. It's not. STIR by itself = is not sufficient to stop telemarketing calls, nor is that our chartered = goal. Not only do IXCs have an incentive to allow telemarketing calls, = as you point out, and arguably carriers are legally required to accept = such calls, but also decisions about such are regulated at a national = level differently per country, and ultimately require = whitelists/blacklists anyway. The goal of STIR is, in the long run, to = prevent "lying" about the source number, as you put it. Regarding support for legitimate "lying": You said that the doctor phone and call-center scenarios required us to = support lying. They don't really, and I think we explained why they = don't in the BOF. They do require third-party authorization, in a = fashion, and I agree that will make the solution more challenging to = deploy. The good news is these cases aren't as common as one would = think - they're common, for sure, but in the grand scheme of things it's = actually a very small population that does this today, compared to the = number of users. It may grow a lot in the future, but that's why we = need an automated mechanism for accomplishing it, and we've discussed = specifying such a mechanism. Regarding whether to do this in the IETF or ITU: Of course we could do this stuff elsewhere. In fact, there was some = off-line discussion about whether to go to 3GPP or ETSI/ATIS instead of = IETF, due to the impedance mismatch of in-band vs. out-of-band in the = WG. I still feel the IETF is the best place to do this work, for many = reasons, but obviously if we fail to make progress quickly then the = motivation to go elsewhere increases. If your goal is to have that = happen, I'd ask why, because it's not like we force you to participate = in STIR. You may think we're wasting our time, but we're not forcing = you to waste *your* time. For example I've never objected to working = groups such as VIPR or P2PSIP being created - I felt they were a = complete waste of time, but not *my* time, only the time of the people = involved in it... and of course I could be wrong about it being a waste = of time. If people want to go work on something they think will be = useful, that's their decision. That's why I argued in-band and = out-of-band should be split apart into separate working groups, because = some folks in each camp thinks doing the other is a waste of their time. Regarding needing to support and prevent MITM: In the general malicious MITM sense, I believe there's consensus that = MITM attacks are not a threat we need to protect against. We do, = though, need to constrain the scope of assertions such that an = organization can only lie about its own numbers (ie, can only claim a = call from/through its domain is from a number it can use). And = obviously an IXC can simply remove STIR info if it wishes to - but if = that happens then governments will eventually get involved. I agree = there is a challenge with call-forwarding scenarios, as I've said many = times in both drafts and emails, but I think there are some ideas of how = to handle it. Regarding the apparent success of email spam filters: I'm sure we all have different experiences, but since you raised your = own... I have 3 email accounts: 2 corporate (Acme+Oracle), one personal = (Yahoo). I spend every morning deleting ~30 spam emails on average from = my inboxes, and throughout the day I delete another ~30 on average. = This is not counting emails I just don't care about, nor counting the = emails that get filtered by spam filters. I have no idea what that is = on a percentage basis (I get a lot of emails), but I don't think = percentages mean anything. The senders of spam don't limit their volume = to a percentage of all emails their targets get. In other words, if you = get 5 spam emails a day, you will get 5 spam emails a day regardless of = how many non-spam emails you get. Also, I don't use SpamSieve (perhaps = I should!), but I believe it uses Bayesian analysis of email *content* = to detect spam - and *content* is something we don't have with call = request signaling. Real-time communication makes it a lot harder to = detect spam, for obvious reasons. -hadriel On Aug 5, 2013, at 4:36 PM, Eric Burger = wrote: > What are the use cases and drivers? >=20 > My understanding is there are two flaws with the current SIP identity = infrastructure. The first is the vast majority of 'calls' use E.164 = (telephone number) addressing. Thus we address them with = sip:+12345567890;user=3Dphone or tel:+1234567890 URI's. The current SIP = identity infrastructure does not handle anything but user@host = identities. Therefore, there is nothing we can do today to assert the = identity of a phone number in SIP. >=20 > The second flaw in the identity infrastructure we have today is = asserted, authenticated identity does not survive passing through middle = boxes and B2BUA's. This comes from a mix of today's scheme being MITM = resistant by design and perhaps a bit overzealous in what is being = protected. The problem is real networks out there have a lot of B2BUA's = in them. >=20 > Complicating matters, we have the extremely complex, real world user = rules that my device can forward calls from an authenticated sender and = that call is supposed to have the authenticated origin of the = authenticated sender (e.g., I am traveling and forward my desk phone to = my mobile phone). The problem here is it is trivial for a bad actor to = induce a good guy to call them so the bad actor can originate a call = with the authenticated good guy as the caller identity. >=20 > Henning at the BOF gave a number of scenarios where the device needs = to lie about its identity. For example, a doctor on the golf course or = at home wants her outgoing caller identity to be that of her office, not = her home or personal phone. Legitimate enterprises regularly contract = with legitimate call centers to make outbound calls on the enterprise's = behalf. In this case, the enterprise want's their own caller identity to = pop up to their customer. They do not want to let the customer know they = have outsourced their call center to Panama. >=20 > We then have the issue of deployment. Assuming we could get beyond the = impossible real-world scenarios that say "prevent a MITM attack, yet = design in a MITM attack" and "provide strong identity of the = origination, yet allow the origin to lie about its identity," we have = some other problems. If that were not enough! >=20 > So, what do we have before us? We have one camp arguing for a = 'practical' solution that can address the robocalling problem. Since the = robocalling problem is primarily a PSTN problem, they are arguing for a = solution that is amenable to PSTN deployment. The PSTN handled this = problem pre-VoIP by noting which ISDN PRI circuit lied about the Caller = ID field. Since most networks were for somewhat trusted, one could trace = back to the bad actor. It was usually an enterprise doing something not = quite nice. >=20 > My understanding is today carriers doing IP interconnect do not bother = to look at the Caller ID field. =46rom an inter exchange carrier's = (IXC's) perspective, there is no reason to. They are being paid by the = carrier that delivers the call to them. The IXC does not route based on = Caller ID, it routes based on dialed number. Note this is the identical = situation that a backbone provider has delivering spam. The backbone = provider has no reason to filter the mail, as they are being paid to = deliver it. Likewise, where the mail comes from does not factor into the = routing of the mail. Too bad for the poor individual or enterprise that = gets a massive bill for premium service numbers or the carrier that gets = hit with massive termination fees. >=20 > So, to address today's PSTN problem, we want to be able to allow a = carrier to determine whom a call is really coming from. Then, once on = the PSTN, the carrier can use all of the legacy PSTN heuristics to deal = with Caller ID spoofing. That leads us to an in band solution, as the = gateway that bridges to the VoIP world would be able to authenticate the = caller's identity claim. This is relatively fast to deploy, as outbound = enterprises would want to do uptake of the technology so they do not get = blocked. The solution would be totally compatible with the existing = Caller ID infrastructure, as carrier network equipment can hack the = display number and name to their heart's content. >=20 > Of course, any legacy Caller ID solution could be trivially hacked by = Caller ID spoofing, as the bad guy can just stuff the Caller ID fields = with something that looks legitimate. In this case, the carrier can = override the Caller ID markings if they do not pass authentication. This = also means that when grandma calls her kids, her kids will see a toxic = waste warning on their Caller ID screens. I do not think grandma will = appreciate that, but since I am not a regulator, that is not my problem. = Grandma is never going to upgrade her ATA. The good news is she will die = in a few decades from never talking with her grand kids, and the problem = of grandma not upgrading will just quietly pass away. >=20 > Did I mention that IXC's have no incentive, or reason for that matter, = to look at the Caller ID fields? Just an observation. >=20 > So, if in band identity authentication is hard, why not do the easy = thing and do out of band identity authentication? Let us again suspend = belief and assume we can solve the very hard (impossible?) problems of = simultaneously supporting no MITM attacks and must have MITM attacks as = well as simultaneously imposting not being able to lie about identity at = the same time that one must be able to lie about identity. >=20 > It is easy to upgrade a few billion cell phones to support an out of = band scheme. Cell phones get cycled every two years or so, and = governments and manufacturers will be very eager to mandate strong = identity in the phone. There are lots of countries that require an = identity card, passport, or even just a credit card to buy a phone or = SIM card. Having the IETF endorse the practice of being able to = cryptographically tie an endpoint to a physical identity would be = nirvana for them. The problem here is grandma again. [Well, there is a = small problem of privacy, but I recall someone in the BOF saying = something akin to "screw privacy."] Most enterprises are running PBX = equipment that is a decade or so old with corresponding software loads. = Unless they are an outbound call center, they have no incentive to = upgrade. Likewise, grandma still only has an analog Caller ID box, maybe = connected to an ATA, but more likely connected to a DMS-10 with a VoIP = gateway hanging off the trunk side. She is never going to have an = endpoint that will do authentication of inbound caller identity. That = means for there to be any penetration, carriers are going to have to = install or upgrade their equipment to take their legacy Caller ID = origination or Caller ID delivery to be out of band aware. Another way = of putting it is they need to take out of band identity authentication = and turn it into in band identity authentication for it to be useful. = Sounds like an argument for in band=85 >=20 > One last comment. I had a micro exchange with Hadriel about the IETF = punting on a PSTN-centric and totalitarian, police state-centric = solution and give it to a body that is used to that sort of engineering, = namely the ITU-T. The IETF can then focus on Internet-based, opt-in, = privacy preserving solutions. The counter argument was that instead of = SPIT, SWATing, and robocolls, look at how bad email spam mitigation is. = The assertion is an Internet-based approach would be much worse for the = user than a PSTN, government-driven approach. >=20 > I just looked at my SpamSieve statistics. I get 99.5% accuracy. I see = 0.1% false positives (grandma going into spam jail) and 0.4% false = negatives (+234 still making it into my inbox). For email, that is = misrouting 5 messages per month. For voice, that would be something like = four or five mishandled calls PER YEAR. >=20 > Sounds a lot better than the 2-3 spit calls I get per week. From pkyzivat@alum.mit.edu Tue Aug 6 06:57:07 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D288121F9D0F for ; Tue, 6 Aug 2013 06:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCh0qfO5Rq9b for ; Tue, 6 Aug 2013 06:57:03 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id F20D021F9A51 for ; Tue, 6 Aug 2013 06:57:02 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id 9PuX1m0040SCNGk56Rx2Yn; Tue, 06 Aug 2013 13:57:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 9Rx11m01e3ZTu2S3VRx1Aa; Tue, 06 Aug 2013 13:57:02 +0000 Message-ID: <520100AC.7040601@alum.mit.edu> Date: Tue, 06 Aug 2013 15:57:00 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: <1E587684-70A3-4782-AD7E-98169F3BB0B1@standardstrack.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375797422; bh=phgymaP6ouH2eMewZPHmlkNHdWBgxWWUKmKOEYsvaxE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BmpkTS77kcmSfpQd/R/vxBXi1YcP6ATdLl834H3A1SuRLqUvJ2W2lzIEvx9DW1123 jbwCBGsyM4XnGmrMZkaZuh7Tq3Q0aHaQpaZGt8m98OapFpVliBip1CNBLYe2ZMstli ipvoZJEz55Fs8PqUC9PpwIYBTDSsiXLZ7z5665zdUUp04bJeKqtc+vsbW2k0R97E8X nTX8kAu98BtaCY2AWZnp/XrAZ42JZ24zgN3kAYuFxtrVybSBM0s11DImpUATW2S7Ep ggRV66by8N11w7xnCGK0Ex/ZwV8I5LXrdkPurfub88S5UxB00yQiaXK6X6BixIZjiv 7qRosXBd8QNXg== Subject: Re: [stir] 15ms??? Where the heck did that come from? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:57:08 -0000 The ideal is that this be done in *parallel*, not *series* with other processing, so that most of the cost doesn't normally add to the delay. Thanks, Paul On 8/6/13 1:38 PM, Hadriel Kaplan wrote: > > Agreed - the budget is not as low as 15ms, but nowhere near as high as 4 seconds. It's actually quite hard to come up with a hard limit though, as a general requirement for STIR for all scenarios. Generally I just think of it as: "as low as we can possibly make it". > > Some people have been talking about it from the perspective of acceptable post-dial-delay (PDD), but I think that's the wrong way to think about it - because STIR is adding additional time to whatever is already deployed today. So the real question is how much *additional* time do we think STIR can introduce, without being a barrier to adoption. That's why for me the topic boils down to "make it super-frigging' fast". > > As an equipment vendor, for example, my employer gets requirements for SIP message processing in the order of single-digit milliseconds if there's no external DB query. Even when we query external databases, we're sometimes required to stop waiting for a DB answer after only tens of milliseconds (or less than 100ms), and forward the call on regardless. This may be because some wholesale carrier SLAs are measured on post-dial-delay; or it may just be because so many systems are involved in call processing, and the cumulative delay would become so untenable, that the carriers decide to require a consistent common max value for all systems. I don't know for sure. Either way, carriers are very sensitive to call delays. > > [As an aside for those who care: according to ITU E.721, the mean delay budget for end-to-end PDD is 3 seconds for local calls, 5 seconds for national long-distance, and 8 seconds for international. But that spec is really conservative and is based on phone-to-phone time. For the SS7 network, a different spec (E.723) gives the end-to-end PDD across the SS7 system as 0.9 seconds for local calls, 2.3 seconds for long-distance, and 4 seconds for international. Mobile phones/networks have a different set of values, I believe. But again, looking at these numbers provides a false sense of time budget for STIR.] > > -hadriel > > > On Aug 5, 2013, at 4:37 PM, Eric Burger wrote: > >> In the STIR BOF I mentioned that the time budget for *additional* processing in the PSTN world would be on the order of 15ms. I need to put a LOT of context around that statement. >> >> Twenty years ago (NOT TODAY), routing special PSTN calls, like free phone or virtual networks, had a very tight time budget. There were both government performance mandates and consumer drivers that ensured carriers routed calls quickly. The big driver is callers might wait up to 2500ms before they would abandon the call. At my company, the saying we had was we never want one of our customers to say, "Why did I ever switch from brand A?" as they hung up the phone and redialed. >> >> Given the latencies of local switches routing to long distance switches, the latencies of breaking out call signaling to make a dozen or so data base lookups, and returning the result so the call could be routed to its destination, our total processing budget was 70ms. That was the days of 30ms access time disks, so you can see the problem. >> >> So, on the one hand, in an IP environment we have a lot more time than 15ms to do authentication steps, as we can do that work in parallel to other routing logic. We are not restricted to adding on the exchanges and algorithms in sequence to other routing processing. >> >> On the other hand, the statement that the budget is 10000ms is beyond reality. Even in a World of Warcraft chat room, no one is going to wait 10 seconds in the hope a connection request is successful. Granted, mobile phones and early VoIP systems have trained users to have a little more patience than 2500ms. However, to expect a user, in a PSTN emulation environment, to hang on for more than 4000ms or 5000ms is wishful thinking._______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From tony@yaanatech.com Tue Aug 6 07:41:37 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67C521F9D02 for ; Tue, 6 Aug 2013 07:41:37 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmSjjbW-zcZD for ; Tue, 6 Aug 2013 07:41:19 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id BC29421F9ABB for ; Tue, 6 Aug 2013 07:41:19 -0700 (PDT) Received: from [192.168.0.18] (pool-71-171-119-184.clppva.fios.verizon.net [71.171.119.184]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 0D3995808A; Tue, 6 Aug 2013 14:41:17 +0000 (UTC) Message-ID: <52010B0C.9090004@yaanatech.com> Date: Tue, 06 Aug 2013 10:41:16 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: Hadriel Kaplan , Eric Burger References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> In-Reply-To: <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040907050303030104000504" Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 14:41:38 -0000 This is a cryptographically signed message in MIME format. --------------ms040907050303030104000504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable It might be worth considering how Art. 5 requirements of the EU Data Retention Directive will be met. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=3DOJ:L:2006:105:005= 4:0063:EN:PDF See also http://ec.europa.eu/dgs/home-affairs/what-we-do/policies/police-cooperati= on/data-retention/index_en.htm Most jurisdictions have equivalent requirements. -t On 8/6/2013 6:50 AM, Hadriel Kaplan wrote: > On Aug 5, 2013, at 4:36 PM, Eric Burger wr= ote: > >> I agree we are not looking at a national security private network anal= ysis. However, we are talking about the potential end of any privacy or a= nonymity for ANY Internet application, more especially Internet multimedi= a application. > How so? Obviously we could theoretically create some mechanism that to= ok all call information from/to everyone and posted it to wikileaks or > whatever, but I don't think we're that stupid. (nor do I think it would= get published by the IETF, nor would anyone use it if we did) > > No one is proposing, for example, that anonymous calls no longer remain= anonymous. Nor that one can't make anonymous calls. > > Your statement seems a bit alarmist. > > -hadriel > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --------------ms040907050303030104000504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINDTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbDMIIFq6ADAgECAhBT hNb1O1n4bTJo0Ah1+gicMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAzMDgwMDAwMDBa Fw0xNDAzMDkyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzYyNzM4NTgzNTAzMSEwHwYJKoZIhvcNAQkBFhJ0b255QHlhYW5hdGVjaC5jb20xDzANBgNV BAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTsANG1JvM4PXw45I4MAIPHPeu6urf2 ml82bH8tuyaGBzUX8AaxBPzChNDbng2wU264FzNKHOVQbiFAH14Xxb1Ih5uPvWh45feCO7PU tSlkdHQSzilC8aOWEdy4+DZXzujp331xSZkjbT1iNWBhjhXubJTDwiYQWT0MBiN3A2IWC+1a PVQvzSZyLLrM7QexO0A3fGuzWtJ9RMUBw++KuB3FQ/nM5iyKhfu2tfP7yiBV4rlwWdbbNe02 PLs2qwMPxIja/JT6tUdgjTn04XUynFgAbTVZniUkra+OodXxk9JGeIGgB+GorAwT0x/TcDeN +DXoHfiBSso2Vmvwx+JkFNECAwEAAaOCAsswggLHMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/ BAQDAgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU+ENL NB52WskhlVdfucmC2XHR4Y8wHQYDVR0RBBYwFIESdG9ueUB5YWFuYXRlY2guY29tMB8GA1Ud IwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUG CCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIw U3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUyMENBJTIw LSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRhdGVkJTJDJTIw T1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7 YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0g BGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGgu Y29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpg hkgBhvhFARADBBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUA A4IBAQDGN/ju6G1Df12wYlBSOzo39vOfJuVASX31X0WWvLieGYzIFPY1IRubH/TCfsUmdGxT 12q1Y6zm1nK+wmPg1xOFhgJNK9+Tfixu2WoKtkG5ZCeWcv48tyUGcr6+UHfvSdLxSQfmNuEU 6T30xH9zEkzChmI9FoUP4V+DjS49bbP9b3KlMNkJDOKrVNI5I233qmYxZZYatMartahrBIwy Qfgor3+M/O8QYzYCAeSMwtpNYNqNXOlLBSCbGt4Y1Kdz7Xgg0fD49vMvRloZ3cMCCv2cLeg2 WlbxotVsn9IbWHq4CZbUKytgREtcbHUgbiIrYnlC4rcSxjX71W1W/u/gDNqgMYIEUjCCBE4C AQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEf MB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEc0AhBThNb1O1n4bTJo0Ah1+gicMAkGBSsOAwIaBQCgggJrMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgwNjE0NDExNlowIwYJKoZI hvcNAQkEMRYEFORb/OvR5aA5rPaDc+b48RB+ZZsoMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcwGCSsGAQQBgjcQBDGBvjCBuzCB pjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzQCEFOE1vU7WfhtMmjQCHX6CJwwgc4GCyqGSIb3DQEJEAILMYG+oIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQ U4TW9TtZ+G0yaNAIdfoInDANBgkqhkiG9w0BAQEFAASCAQA35KgXheSAXu5CZgAVyQB+55iw wzQuKXFm6RnPs05BNSzOtQHLodvjyjMqC2W/1KmBHEns26P+4BTTLMrmZeQHfGoh7g3ZU4it wbJxOIFLr11b5/neednQeb6df7lcFJWmU4shQNIcgLWJWYTLNxZ71Kh+XQmHInBT22361XWX 1O66CQWTuE/w3jq1XmBfvnv4c3Wf9dPkNgDedP2Lujwd0BJEKsJc2YHA167kbSDvqDQP/0tV +CXgU9FvYswmqhHT6Ij8lXLA/SNFxmVYytCqMMIlgzkwuqXnusf1OhrTaN0DYdxgB80LBKvD a9l69rU5r/SxYARkMTcAUPLgjjfhAAAAAAAA --------------ms040907050303030104000504-- From york@isoc.org Tue Aug 6 07:42:26 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7F21F9D92 for ; Tue, 6 Aug 2013 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.466 X-Spam-Level: X-Spam-Status: No, score=-104.466 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2HoxUhmcgnL for ; Tue, 6 Aug 2013 07:42:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7D90421F9DF3 for ; Tue, 6 Aug 2013 07:42:21 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB066.namprd06.prod.outlook.com (10.242.187.145) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 14:42:18 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.8]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.173]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 14:42:18 +0000 From: Dan York To: Hadriel Kaplan , Eric Burger Thread-Topic: Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: [stir] What are we trying to do, and where do we want to end up? Thread-Index: AQHOkjhWgM0umtqkfUa1vnKwttnvh5mIMnyA///MTQA= Date: Tue, 6 Aug 2013 14:42:18 +0000 Message-ID: In-Reply-To: <0E3C98D1-3BED-4A7E-A5B1-5C6197706845@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.4] x-forefront-prvs: 0930AAFAD9 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(479174003)(377454003)(199002)(189002)(37854004)(49866001)(16406001)(36756003)(54316002)(53806001)(54356001)(65816001)(47736001)(47976001)(74366001)(76482001)(77982001)(79102001)(59766001)(76176001)(56776001)(47446002)(63696002)(74502001)(74662001)(74876001)(81342001)(46102001)(76796001)(50986001)(80022001)(83322001)(80976001)(19580405001)(19580395003)(31966008)(69226001)(81542001)(76786001)(74706001)(51856001)(83072001)(77096001)(4396001)(56816003)(504514002)(502464002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB066; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <2883E2EED1B6EF48A0C4F94E658C2810@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: IETF STIR Mail List Subject: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 14:42:27 -0000 So I feel compelled to reply to this point... On 8/6/13 9:47 AM, "Hadriel Kaplan" wrote: >Regarding support for legitimate "lying": >You said that the doctor phone and call-center scenarios required us to >support lying. They don't really, and I think we explained why they >don't in the BOF. They do require third-party authorization, in a >fashion, and I agree that will make the solution more challenging to >deploy. The good news is these cases aren't as common as one would think >- they're common, for sure, but in the grand scheme of things it's >actually a very small population that does this today, compared to the >number of users. It may grow a lot in the future, but that's why we need >an automated mechanism for accomplishing it, and we've discussed >specifying such a mechanism. I am not so sure that this is a "very small population that does this today" and I also want to emphasize that this is far more than just doctors and call-centers. Prior to joining the Internet Society almost two years ago, I spent four years working for Voxeo, a company that provides an application platform that among its many uses can enable a wide range of outbound calling applications. Companies would build applications on platforms such as Voxeo's (and other competitor's) and then sell them out to customers. Among the applications I remember hearing about (on Voxeo's platform and other platforms) were: - MANY school systems using outbound notification systems for weather-related issues ("no school due to snow"), upcoming events/games, emergency issues (ex. school shootings), etc. I remember hearing of at least one case where there were *daily* calls going home to parents indicating whether Johnny was in school and what Johnny's homework was. - Communities using outbound notification systems to alert people to emergencies in the region, including weather and crime events. - Pharmacies using automated calls to alert people that prescriptions were ready. - Banks using automated calls as part of a security system to call back a number.=20 - Debt collection calls. - Companies using outbound apps to do pre-screening as part of an interview process (and sometimes quite a lengthy process). - Customer service surveys - Problem resolution updates (ex. a call saying a service has been restored) - Invitations to events with the ability to RSVP within the call - Confirmation calls from various services (ex. doctors, dentists, auto services) asking me to confirm whether I am going to be at my designated appointment - Online games that have used outbound calls as part of the experience (One that I played that was related to a movie was kind of spooky in how it called you to ask you questions... and then used your (recorded) answers against you later in the game!) And I could keep on going and going... I think I heard of a ski area making daily calls out with ski conditions! Some of these that I listed might be thought of as a "call center" app, but others are people trying new and different ways of playing with outbound telephony. And I can say that with my previous employer there were some very large customers with VERY large outbound calling volumes. The point is that these are increasingly common types of calls to receive. We probably receive 1-2 of these calls each week here at my house, either to confirm appointments or to be notified of prescriptions. I also routinely get calls from airlines when traveling. Once school starts up I'll be getting occasional automated calls related to our kids' classes and events. Yes, you could say these are "robocalls"... but they are robocalls that **I want to receive**. I have either signed up for the service or allowed them to call me. Now, many of these calls may be implemented by the calling entity from within their own phone network and therefore can have their origin easily identified as being from that company. But many other calls may be implemented by any of these providers of "cloud" application platforms... and there are now MANY such "communications applications platforms" who will perform this outbound calling on your behalf. In some of those cases, maybe the entity who wants the calls done doesn't care about what Caller ID is on the call. But in many of the cases the entity will want the Caller ID to be *their* ID, either to help the called party believe the call is legit or because the caller may want to hide the fact that they are using some other service to deliver the actual outbound call. So beyond simply doctors' seeking to display their office number when calling from other lines - and all the "traditional" call-center outbound calling, there are a very wide range of applications out there that are now being deployed to provide more efficient customer service or to enable new experiences. We *do* need to account for these type of use cases in creating a system of secure origin authentication for IP communications. And yes, I know we've discussed this... but I cringe every time I see someone dismissing this use case as less common or only done by a small number of people. Dan From michael.hammer@yaanatech.com Tue Aug 6 07:48:39 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE2221F9EF6 for ; Tue, 6 Aug 2013 07:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK-B8BHUkV2r for ; Tue, 6 Aug 2013 07:48:33 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id BB29C21F9E9C for ; Tue, 6 Aug 2013 07:48:30 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 6 Aug 2013 07:48:30 -0700 From: Michael Hammer To: "york@isoc.org" , "hadriel.kaplan@oracle.com" , "eburger@standardstrack.com" Thread-Topic: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? Thread-Index: AQHOkrMsdFwKvLmMT0OA5FmcEDkH65mIQj9w Date: Tue, 6 Aug 2013 14:48:29 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2401A@EX2K10MB1.corp.yaanatech.com> References: <0E3C98D1-3BED-4A7E-A5B1-5C6197706845@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.237] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005B_01CE9292.7C57EA60" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 14:48:39 -0000 ------=_NextPart_000_005B_01CE9292.7C57EA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, but that doesn't mean you have to lie about the true originator of the call separate from what to display on caller ID or what to provide as a call-back number. Many of the problems arise from conflating multiple purposes into the same field. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan York Sent: Tuesday, August 06, 2013 10:42 AM To: Hadriel Kaplan; Eric Burger Cc: IETF STIR Mail List Subject: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? So I feel compelled to reply to this point... On 8/6/13 9:47 AM, "Hadriel Kaplan" wrote: >Regarding support for legitimate "lying": >You said that the doctor phone and call-center scenarios required us to >support lying. They don't really, and I think we explained why they >don't in the BOF. They do require third-party authorization, in a >fashion, and I agree that will make the solution more challenging to >deploy. The good news is these cases aren't as common as one would >think >- they're common, for sure, but in the grand scheme of things it's >actually a very small population that does this today, compared to the >number of users. It may grow a lot in the future, but that's why we >need an automated mechanism for accomplishing it, and we've discussed >specifying such a mechanism. I am not so sure that this is a "very small population that does this today" and I also want to emphasize that this is far more than just doctors and call-centers. Prior to joining the Internet Society almost two years ago, I spent four years working for Voxeo, a company that provides an application platform that among its many uses can enable a wide range of outbound calling applications. Companies would build applications on platforms such as Voxeo's (and other competitor's) and then sell them out to customers. Among the applications I remember hearing about (on Voxeo's platform and other platforms) were: - MANY school systems using outbound notification systems for weather-related issues ("no school due to snow"), upcoming events/games, emergency issues (ex. school shootings), etc. I remember hearing of at least one case where there were *daily* calls going home to parents indicating whether Johnny was in school and what Johnny's homework was. - Communities using outbound notification systems to alert people to emergencies in the region, including weather and crime events. - Pharmacies using automated calls to alert people that prescriptions were ready. - Banks using automated calls as part of a security system to call back a number. - Debt collection calls. - Companies using outbound apps to do pre-screening as part of an interview process (and sometimes quite a lengthy process). - Customer service surveys - Problem resolution updates (ex. a call saying a service has been restored) - Invitations to events with the ability to RSVP within the call - Confirmation calls from various services (ex. doctors, dentists, auto services) asking me to confirm whether I am going to be at my designated appointment - Online games that have used outbound calls as part of the experience (One that I played that was related to a movie was kind of spooky in how it called you to ask you questions... and then used your (recorded) answers against you later in the game!) And I could keep on going and going... I think I heard of a ski area making daily calls out with ski conditions! Some of these that I listed might be thought of as a "call center" app, but others are people trying new and different ways of playing with outbound telephony. And I can say that with my previous employer there were some very large customers with VERY large outbound calling volumes. The point is that these are increasingly common types of calls to receive. We probably receive 1-2 of these calls each week here at my house, either to confirm appointments or to be notified of prescriptions. I also routinely get calls from airlines when traveling. Once school starts up I'll be getting occasional automated calls related to our kids' classes and events. Yes, you could say these are "robocalls"... but they are robocalls that **I want to receive**. I have either signed up for the service or allowed them to call me. Now, many of these calls may be implemented by the calling entity from within their own phone network and therefore can have their origin easily identified as being from that company. But many other calls may be implemented by any of these providers of "cloud" application platforms... and there are now MANY such "communications applications platforms" who will perform this outbound calling on your behalf. In some of those cases, maybe the entity who wants the calls done doesn't care about what Caller ID is on the call. But in many of the cases the entity will want the Caller ID to be *their* ID, either to help the called party believe the call is legit or because the caller may want to hide the fact that they are using some other service to deliver the actual outbound call. So beyond simply doctors' seeking to display their office number when calling from other lines - and all the "traditional" call-center outbound calling, there are a very wide range of applications out there that are now being deployed to provide more efficient customer service or to enable new experiences. We *do* need to account for these type of use cases in creating a system of secure origin authentication for IP communications. And yes, I know we've discussed this... but I cringe every time I see someone dismissing this use case as less common or only done by a small number of people. Dan _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_005B_01CE9292.7C57EA60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw NjE0NDgyOFowIwYJKoZIhvcNAQkEMRYEFC1bYU47SsB+ndx52BbqWVNnjdIiMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAdwVIo4+tpHtD/XBE1cPLrc38Md0P5SBw7QTwQ/va ymXxgm3gRLnAJZAQfkH9pyzRZ60KlTtGDu2GB6hhzTBIZRasczIgFGEpTieydwrCaK0kbA3RMQjA 5X0UZPKz2bMBZ5KjrNpHzzYI1wiZJLDoghJpiK4XyGmsfTYX9Rcgxp7Kc9GHlTNhnyH/AFjzlGfy +UV8se6azSg0i+IBCeXJDc2h5O4S1kXNhJgdKgwD5XI5yqeP8joOWe6ZBOYERTL+Xm2SZfRoTqGp dtC6fNktLoPPHCxXzS+CuSnF5VKiv0rRtBxVAc5H9sd3DMhMTXX3jW6QA+9pU3smBq6/rI5hggAA AAAAAA== ------=_NextPart_000_005B_01CE9292.7C57EA60-- From pkyzivat@alum.mit.edu Tue Aug 6 08:07:27 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AC521F9A37 for ; Tue, 6 Aug 2013 08:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa7aZgWAPXXV for ; Tue, 6 Aug 2013 08:07:22 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id A19D121F9EF8 for ; Tue, 6 Aug 2013 08:07:14 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta14.westchester.pa.mail.comcast.net with comcast id 9Pwo1m0030SCNGk5ET7DmL; Tue, 06 Aug 2013 15:07:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 9T7C1m0133ZTu2S3VT7DQo; Tue, 06 Aug 2013 15:07:13 +0000 Message-ID: <52011120.2000206@alum.mit.edu> Date: Tue, 06 Aug 2013 17:07:12 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> <51F9F08C.3050700@dcrocker.net> <51FA14C9.6030903@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375801633; bh=sJbDm/tfuqTpy48IU3Cs+8p0A9qc2jGiQFw2mDwwZFA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BBvv73lDvkVTL8ZTHVj2A8MX76pjTuTY+K08pR/Hf3h2qjoGQvv7CZ/h9TKhkIRGa lvX86wZTgSRT0R+wjDKcwkyCQizu7tbGeIRJcaUesrBkbkBlIyVNr2FQ8rh4osL5Hk PK69XVDzlzC4c/XsJnaVjfB123hag9xTbSqoprMDsJhfkdx40c7BT1jrtFpFHEV2t8 Y93qlfUZVGw3MFPXRiBdueIFGN9BNSmGWnd2huDwqFdcpF6qw1AMF7EegNF/Flsaht f+x6NxKZkYOW8CfD5QFyTt4stDyiNSmXboEaA+JFjREn35DV6igZglSZNMWhke4VIh 4CZf33RMmNR/A== Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:07:28 -0000 +1 On 8/1/13 2:12 PM, Richard Barnes wrote: > On Thu, Aug 1, 2013 at 11:29 AM, Hadriel Kaplan > > wrote: > > > I think the concern, and I have it too, is that when one mixes oil > and water in a working group there are likely to be (1) differing > views of what's acceptable/not in terms of threats, deployment > models and protocols, and operation/management of it, and (2) cases > of contention for the same resources, such as vying for time in WG > meetings. > > My interpretation of the charter is that if such things happen, then > in-band wins; once in-band is submitted to IESG, out-of-band gets > all the time. For now we can talk about both in mailing list, and > of course people can continue to work on out-of-band, discuss it in > WG meetings if there's time, etc. And when we work on our documents > we have to keep out-of-band in mind... although if we do find > there're some big differences or more documentation work required > due to out-of-band, then my assumption is we'd separate the > out-of-band into separate docs to work on later. > > > Thanks, Hadriel. That matches my thinking. > > --Richard > > > > -hadriel > > > On Aug 1, 2013, at 5:06 AM, Richard Barnes wrote: > > > On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker > wrote: > > On 8/1/2013 9:26 AM, Richard Barnes wrote: > > > > That's why I didn't propose putting it in the charter :) > Obviously, we > > will try to clarify this in the charter. > > > > > > Color me even more confused than usual (and that's going some.) > > > > Advice from the cognizant AD about what technical issues to > "consider" when working is usually treated as definitive direction, > absent an overriding appeal (which isn't ever requested, nevermind > sustained.) > > > > That's an overstatement. To quote the Tao: > > "Many people look at the ADs as somewhat godlike creatures ... > However, most ADs are nearly indistinguishable from mere mortals and > rarely speak from mountaintops." > > > > More to the point, I didn't mean it that way. That's why, for > example, I said "I would encourage..." and not "Thou shalt..." I > consider the charter to be the real commitment. > > > > > > > > Perhaps you could respond to the substance of the concern I > raised in my previous note? > > > > I take this to mean your concern that my "keep in mind" > suggestion would encourage people to work on things in parallel > rather than sequence. > > > > The intent is actually the opposite, to help people get > interested in out-of-band more engaged in in-band. If the in-band > solution requires parts (A,B,C) and out-of-band requires (A,B,D), > then people interested in out-of-band should be interested in A and > B, and not just checked out of the WG until in-band is done. > > > > --Richard > > > > > > > > > > d/ > > > > > > -- > > Dave Crocker > > Brandenburg InternetWorking > > bbiw.net > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From york@isoc.org Tue Aug 6 08:21:29 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E16521F9A1B for ; Tue, 6 Aug 2013 08:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzKDIcsqXetD for ; Tue, 6 Aug 2013 08:21:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id BF98321F9A05 for ; Tue, 6 Aug 2013 08:21:05 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB068.namprd06.prod.outlook.com (10.242.187.155) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 15:21:03 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.8]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.173]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 15:21:02 +0000 From: Dan York To: Michael Hammer , "hadriel.kaplan@oracle.com" , "eburger@standardstrack.com" Thread-Topic: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? Thread-Index: AQHOkrQIQRIrse6jEkGI78te3wJswJmICKYA Date: Tue, 6 Aug 2013 15:21:01 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2401A@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.4] x-forefront-prvs: 0930AAFAD9 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(479174003)(377454003)(199002)(189002)(36756003)(49866001)(47976001)(19580405001)(63696002)(54316002)(83322001)(80022001)(4396001)(74366001)(47736001)(19580395003)(50986001)(69226001)(77096001)(74662001)(74876001)(56816003)(76796001)(76176001)(77982001)(31966008)(59766001)(74706001)(79102001)(74502001)(80976001)(76786001)(47446002)(83072001)(51856001)(81342001)(54356001)(46102001)(56776001)(76482001)(81542001)(53806001)(16406001)(65816001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB068; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <586E5C4773AA734A9CD6F7AFB006E0EB@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:21:29 -0000 Mike, On 8/6/13 10:48 AM, "Michael Hammer" wrote: >Yes, but that doesn't mean you have to lie about the true originator of >the >call separate from what to display on caller ID or what to provide as a >call-back number. Sure... but the reality is that if we have a field providing origin identification it will probably be used for both. =20 >Many of the problems arise from conflating multiple purposes into the same >field. Perhaps we need to be more clear on who is the consumer of the field(s) we are creating: - Are we trying to help consumers know who is calling them? - Are we trying to help carriers / service providers be able to track and potentially block calls? - Are we trying to do both? Dan From dhc@dcrocker.net Tue Aug 6 08:23:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E848821F9F1C for ; Tue, 6 Aug 2013 08:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q+-yyYG7Iz4 for ; Tue, 6 Aug 2013 08:23:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0534421F9E2B for ; Tue, 6 Aug 2013 08:23:15 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r76FN4sW008629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 08:23:12 -0700 Message-ID: <520114D6.2050205@dcrocker.net> Date: Tue, 06 Aug 2013 08:23:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> <702EA082-43B7-490D-B909-00630A195CE4@vigilsec.com> In-Reply-To: <702EA082-43B7-490D-B909-00630A195CE4@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 06 Aug 2013 08:23:12 -0700 (PDT) Cc: IETF STIR Mail List , Stephen Kent Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:23:21 -0000 On 8/5/2013 12:44 PM, Russ Housley wrote: > The threat document is quite different if it cover an in-band mechanism or both an in-band and an out-of-band mechanism. Do you have any thoughts on this? Do you have proposed charter text? Russ, No doubt it's my naivete about the technical side of security work, but it isn't obvious to me why your assertion is correct. Please explain the nature of the differences that you see. By way of example, imagine an out-of-band mechanism that merely takes the in-band signature and stashes it somewhere, much like a cookie mechanism. The storage environment can see the retrieval attributes in the clear -- the same as any other transit handling node -- I suppose, but the rest of the information won't be accessible to it. Nevermind that, even before we have the charter saying that out-of-band is to be deferred, we have yet-another introduction of it into initial technical discussions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Tue Aug 6 08:26:29 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEEA21F9C53 for ; Tue, 6 Aug 2013 08:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWuAJqR+MaHJ for ; Tue, 6 Aug 2013 08:26:24 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 54F8421F9B5F for ; Tue, 6 Aug 2013 08:26:24 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 6 Aug 2013 08:26:24 -0700 From: Michael Hammer To: "york@isoc.org" , "hadriel.kaplan@oracle.com" , "eburger@standardstrack.com" Thread-Topic: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? Thread-Index: AQHOkrMsdFwKvLmMT0OA5FmcEDkH65mIQj9wgAB+0YD//4wVUA== Date: Tue, 6 Aug 2013 15:26:22 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC24127@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2401A@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.237] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C2_01CE9297.C7069F20" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:26:30 -0000 ------=_NextPart_000_00C2_01CE9297.C7069F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All of them. -----Original Message----- From: Dan York [mailto:york@isoc.org] Sent: Tuesday, August 06, 2013 11:21 AM To: Michael Hammer; hadriel.kaplan@oracle.com; eburger@standardstrack.com Cc: stir@ietf.org Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? Mike, On 8/6/13 10:48 AM, "Michael Hammer" wrote: >Yes, but that doesn't mean you have to lie about the true originator of >the call separate from what to display on caller ID or what to provide >as a call-back number. Sure... but the reality is that if we have a field providing origin identification it will probably be used for both. >Many of the problems arise from conflating multiple purposes into the >same field. Perhaps we need to be more clear on who is the consumer of the field(s) we are creating: - Are we trying to help consumers know who is calling them? - Are we trying to help carriers / service providers be able to track and potentially block calls? - Are we trying to do both? Dan ------=_NextPart_000_00C2_01CE9297.C7069F20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw NjE1MjYyMVowIwYJKoZIhvcNAQkEMRYEFIErt+QVrs3EQIhRkWL2EjihxxS2MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAJXI09Pbdrbh4xrsMMzCtnTAZfcqwLjSCCtGz+6uN edTNAyC7wcFb82OXJYwwbpL9W7bbVx6aZm5AXaWzPKfMwdNtXoam2zb5qFkH/0j2Y2rV+FEuvULQ VCfw5ZHKqsA5fKSe21oQJiQreltkwK3pzCMnQMCEEj5INbviAH2Xc7biJV7MGCkejdIxhkHRSgzA PBu7oTVOLWtdeazw1c9+AkGKPgV+G34FcxPsTUx9TZMFlp9lPXv8NEVbFP9auxXnUtm6PeTp63je DUuTHVemaHZy7BUzfHcvcsrTw7lCqHuH4fOauw1QBatcTAwR4Hfwi+HIkJqKwxJz2yF8sRFv6AAA AAAAAA== ------=_NextPart_000_00C2_01CE9297.C7069F20-- From richard@shockey.us Tue Aug 6 08:58:37 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7739A21F99A2 for ; Tue, 6 Aug 2013 08:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.852 X-Spam-Level: X-Spam-Status: No, score=-100.852 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbg8P9foF9Ol for ; Tue, 6 Aug 2013 08:58:32 -0700 (PDT) Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 8B08B21F9C72 for ; Tue, 6 Aug 2013 08:58:32 -0700 (PDT) Received: (qmail 29818 invoked by uid 0); 6 Aug 2013 15:58:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.mail.unifiedlayer.com with SMTP; 6 Aug 2013 15:58:09 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=/R40gVzrxaNXw7THtKVCQvYixA6TN0d2sCNEvFUbQx4=; b=HC39XUgHKoznb+655QYvosb18n6XPvajagJflEoocY5cPbuC/bm6R8ElxMmkAhE4d1t9UMABu0yBi2cGnBhsnAtglHf4I6VQCqjPQDF5pCAJJcf4mY8v2sHHkLCHlrp5; Received: from [71.114.100.16] (port=50022 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V6jeC-00040t-Hr; Tue, 06 Aug 2013 09:58:08 -0600 From: "Richard Shockey" To: "'Dan York'" , "'Michael Hammer'" , , References: <00C069FD01E0324C9FFCADF539701DB3BBC2401A@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Date: Tue, 6 Aug 2013 11:58:06 -0400 Message-ID: <00ca01ce92bd$be2da620$3a88f260$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIhgpPXaUUfj1EOwxNlPUhl1eXhj5jidFFw X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:58:37 -0000 On 8/6/13 10:48 AM, "Michael Hammer" wrote: >Yes, but that doesn't mean you have to lie about the true originator of >the call separate from what to display on caller ID or what to provide >as a call-back number. Sure... but the reality is that if we have a field providing origin identification it will probably be used for both. >Many of the problems arise from conflating multiple purposes into the >same field. Perhaps we need to be more clear on who is the consumer of the field(s) we are creating: - Are we trying to help consumers know who is calling them? - Are we trying to help carriers / service providers be able to track and potentially block calls? - Are we trying to do both? [RS> ] IMHO all of them as Hammer points out. We need both the hammer and the chain saw. We need to ultimately track the origin. The SIP/PSTN gateway case is going to be more challenging but that is a totally orthogonal issue. I'm sorry to harp on this but legitimate use of anonymity cannot be used to shield criminal fraud. That is of course another problem but they are interrelated. I'm not tracking INSIPID but I'm disturbed that some folks are talking about modifying its intended use case. Dan _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From housley@vigilsec.com Tue Aug 6 09:25:46 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112A221F894E for ; Tue, 6 Aug 2013 09:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.708 X-Spam-Level: X-Spam-Status: No, score=-102.708 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH2IjYkcYB-S for ; Tue, 6 Aug 2013 09:25:41 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id E790621F90CC for ; Tue, 6 Aug 2013 09:25:22 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 94134F24085; Tue, 6 Aug 2013 12:25:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id A6GUCL3yX0TH; Tue, 6 Aug 2013 12:25:18 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E3028F2408A; Tue, 6 Aug 2013 12:25:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <29522_1375782099_5200C4D3_29522_3064_1_B5939C6860701C49AA39C5DA5189448B0B76DE@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Tue, 6 Aug 2013 12:25:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3B73852F-42DD-4350-A83E-04DBB34DBAB6@vigilsec.com> References: <8BE71738-46A3-4462-AE74-6C1B9CD4389D@vigilsec.com> <29522_1375782099_5200C4D3_29522_3064_1_B5939C6860701C49AA39C5DA5189448B0B76DE@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: Philippe Fouquart X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] IETF 87 STIR BOF Minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:25:46 -0000 Does this capture it? Philipe: At Orange, we have similar problems in countries where we operate. There are variations, and the exact nature of the problem may depend on the national numbering policies and what they permit. On Aug 6, 2013, at 5:41 AM, = wrote: > Thanks to the note takers.=20 >=20 > Under slide 23. (search on " if the numbering policies are legal or = not") >=20 > Actually national numbering policies per se are always "legal", by = construction. I think my intervention was more along the lines of "There = are variations, and the exact nature of the problem may depend on the = national numbering policies and what they permit, or consider "legal" or = not, eg suballocation." If the former phrase could be changed into the = latter, it'd probably be clearer. Thanks. >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Russ Housley > Sent: Monday, August 05, 2013 9:32 PM > To: IETF STIR Mail List > Subject: [stir] IETF 87 STIR BOF Minutes >=20 > http://www.ietf.org/proceedings/87/minutes/minutes-87-stir >=20 > Thanks very much to Jean Mahoney and Olafur Gudmundsson for taking = notes. >=20 > I assembled the minutes from these notes and then posted them. Please = send any corrections to the mail list. >=20 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 From hadriel.kaplan@oracle.com Tue Aug 6 09:28:52 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA9D21E8082 for ; Tue, 6 Aug 2013 09:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.46 X-Spam-Level: X-Spam-Status: No, score=-7.46 tagged_above=-999 required=5 tests=[AWL=1.139, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXOl7STLo7CS for ; Tue, 6 Aug 2013 09:28:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id CC15121E805A for ; Tue, 6 Aug 2013 09:28:46 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76GShqt023815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 16:28:44 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76GShS9024948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 16:28:43 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76GShO0023578; Tue, 6 Aug 2013 16:28:43 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 09:28:42 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 6 Aug 2013 12:28:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <14D8F2EE-323C-49EE-BAB2-BA9A04551799@oracle.com> References: To: Dan York X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:28:52 -0000 Somehow I knew someone would object to that. :)=20 I recognize there are a CRAP-LOAD of perfectly legitimate, = good-and-wholesome automated outbound dialers. But the only ones that = matter in the "we need to let people lie about their number" context, = are the ones who need to legitimately represent a number other than one = they were assigned through the normal number assignment process. If a = bank generates automated outbound calls, and does so from a system they = control, there's no problem. The challenge is to allow them to = authorize such calls from a system they don't directly control - such as = an outsourcing company - whether that be a call-center or cloud-based = service or whatever. There are a LOT of those folks too. And obviously we MUST support such = use-cases - no one's ever claimed we wouldn't need to handle it, and = handle it in such a way that those outsourcing companies could generate = STIR-validated calls for those source identities. We've even talked = about how that could work, with authorization in either an IP-based = automated protocol manner, or even with faxed documents or carrier = pigeons. The reason I said it "will make the solution more challenging to = deploy", is because today those folks don't even have to send faxes or = carrier pigeons; so it requires those folks to do something new, no = matter how much or little effort it may be. So my point was: the good news is it's not like the number of folks who = have to do something new is 7 Billion. Compared to the number of users = in the system world-wide, it's a small population that has to do = something new. My guess is it's in the same ballpark of 50k... or 100k, = or 200k, or it may well be in the 1 million for all I know... but still = compared to 7 Billion it's a small population. But in a separate email I also tried to explain that coming up with = these numbers is a bit dangerous. When new things are enabled, they = sometimes take on a life of their own, and expand at surprising rates. = For example, most people didn't think number portability would be as = popular is it turned out to be. They didn't realize that the lack of = number portability before-hand was creating a self-fulfilling statistic = of few people changing carriers; once number portability was possible, = people started switching carriers in droves. Likewise it's possible = that deploying source identity validation on a large scale in carriers, = might enable uses of E.164 numbers as identities in ways we haven't = foreseen, resulting in a very different usage pattern. (I can think of = several ways that could happen) Having said that, obviously we also have to be careful not to = over-engineer and produce a solution which doesn't address the existing = problem in a way the existing stake-holders can use it in the world we = live in today. -hadriel On Aug 6, 2013, at 10:42 AM, Dan York wrote: > So I feel compelled to reply to this point... >=20 >=20 > On 8/6/13 9:47 AM, "Hadriel Kaplan" wrote: >=20 >> Regarding support for legitimate "lying": >> You said that the doctor phone and call-center scenarios required us = to >> support lying. They don't really, and I think we explained why they >> don't in the BOF. They do require third-party authorization, in a >> fashion, and I agree that will make the solution more challenging to >> deploy. The good news is these cases aren't as common as one would = think >> - they're common, for sure, but in the grand scheme of things it's >> actually a very small population that does this today, compared to = the >> number of users. It may grow a lot in the future, but that's why we = need >> an automated mechanism for accomplishing it, and we've discussed >> specifying such a mechanism. >=20 > I am not so sure that this is a "very small population that does this > today" and I also want to emphasize that this is far more than just > doctors and call-centers. Prior to joining the Internet Society almost = two > years ago, I spent four years working for Voxeo, a company that = provides > an application platform that among its many uses can enable a wide = range > of outbound calling applications. Companies would build applications = on > platforms such as Voxeo's (and other competitor's) and then sell them = out > to customers. Among the applications I remember hearing about (on = Voxeo's > platform and other platforms) were: >=20 > - MANY school systems using outbound notification systems for > weather-related issues ("no school due to snow"), upcoming = events/games, > emergency issues (ex. school shootings), etc. I remember hearing of at > least one case where there were *daily* calls going home to parents > indicating whether Johnny was in school and what Johnny's homework = was. >=20 > - Communities using outbound notification systems to alert people to > emergencies in the region, including weather and crime events. >=20 > - Pharmacies using automated calls to alert people that prescriptions = were > ready. >=20 > - Banks using automated calls as part of a security system to call = back a > number.=20 >=20 > - Debt collection calls. >=20 > - Companies using outbound apps to do pre-screening as part of an > interview process (and sometimes quite a lengthy process). >=20 > - Customer service surveys >=20 > - Problem resolution updates (ex. a call saying a service has been > restored) >=20 > - Invitations to events with the ability to RSVP within the call >=20 > - Confirmation calls from various services (ex. doctors, dentists, = auto > services) asking me to confirm whether I am going to be at my = designated > appointment >=20 > - Online games that have used outbound calls as part of the experience > (One that I played that was related to a movie was kind of spooky in = how > it called you to ask you questions... and then used your (recorded) > answers against you later in the game!) >=20 > And I could keep on going and going... I think I heard of a ski area > making daily calls out with ski conditions! Some of these that I = listed > might be thought of as a "call center" app, but others are people = trying > new and different ways of playing with outbound telephony. And I can = say > that with my previous employer there were some very large customers = with > VERY large outbound calling volumes. >=20 > The point is that these are increasingly common types of calls to = receive. > We probably receive 1-2 of these calls each week here at my house, = either > to confirm appointments or to be notified of prescriptions. I also > routinely get calls from airlines when traveling. Once school starts = up > I'll be getting occasional automated calls related to our kids' = classes > and events. >=20 > Yes, you could say these are "robocalls"... but they are robocalls = that > **I want to receive**. I have either signed up for the service or = allowed > them to call me. >=20 > Now, many of these calls may be implemented by the calling entity from > within their own phone network and therefore can have their origin = easily > identified as being from that company. But many other calls may be > implemented by any of these providers of "cloud" application = platforms... > and there are now MANY such "communications applications platforms" = who > will perform this outbound calling on your behalf. >=20 > In some of those cases, maybe the entity who wants the calls done = doesn't > care about what Caller ID is on the call. But in many of the cases the > entity will want the Caller ID to be *their* ID, either to help the = called > party believe the call is legit or because the caller may want to hide = the > fact that they are using some other service to deliver the actual = outbound > call. >=20 > So beyond simply doctors' seeking to display their office number when > calling from other lines - and all the "traditional" call-center = outbound > calling, there are a very wide range of applications out there that = are > now being deployed to provide more efficient customer service or to = enable > new experiences. >=20 > We *do* need to account for these type of use cases in creating a = system > of secure origin authentication for IP communications. And yes, I = know > we've discussed this... but I cringe every time I see someone = dismissing > this use case as less common or only done by a small number of people. >=20 > Dan >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Tue Aug 6 09:54:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985B021F9ED2 for ; Tue, 6 Aug 2013 09:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17iG5n28WcdW for ; Tue, 6 Aug 2013 09:54:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B7B6921F9F1B for ; Tue, 6 Aug 2013 09:54:12 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76GsAfc019623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 16:54:11 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76Gs9Og011796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 16:54:10 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76Gs9XS022713; Tue, 6 Aug 2013 16:54:09 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 09:54:09 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <00ca01ce92bd$be2da620$3a88f260$@shockey.us> Date: Tue, 6 Aug 2013 12:54:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6295AE32-3C75-4E09-9D9F-52E7BF9CF797@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2401A@EX2K10MB1.corp.yaanatech.com> <00ca01ce92bd$be2da620$3a88f260$@shockey.us> To: "Richard Shockey" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:54:35 -0000 On Aug 6, 2013, at 11:58 AM, "Richard Shockey" = wrote: > I'm sorry to harp on this but legitimate use of anonymity > cannot be used to shield criminal fraud. That is of course another = problem > but they are interrelated. =20 I'm hoping we'll be ok on that topic. I don't really equate STIR with = tracking the bad guys down - I mean even STIR doesn't tell you where = they came in from, and truly bad guys would just not sign their stuff = using STIR anyway. You can generate all the anonymous calls you want, = but even today we can eventually track them down. It's a major PITA = because it requires going carrier-by-carrier comparing numerous CDR = records and system logs, but it is doable and is actually performed. =20 We've talked about providing something to help track stuff back (the = header list of SPIDs idea), but it's kinda orthogonal to the current = STIR deliverables. ISTM we can add it as a milestone later if we want = to. That one would have some odd privacy implications, and need careful = consideration, but I think it's possible to do. > I'm not tracking INSIPID but I'm disturbed that > some folks are talking about modifying its intended use case.=20 We have a very hard time doing things in RAI for purely = operational-improvement purposes. We want new features we can sell, = instead. (and I include myself in that general problem too) It's ok though - even with a different Session-ID value per domain, but = consistent within portions of the domain, will make back-tracking = easier. End-to-end Session-ID was never going to avoid having to look = at CDR records to back-track, anyway... just reduce how many CDRs you = have to look at. It didn't, for example, tell you what carriers the = request came in from/through. -hadriel From housley@vigilsec.com Tue Aug 6 09:56:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D4221F9E83 for ; Tue, 6 Aug 2013 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e19ZW9RsqM7K for ; Tue, 6 Aug 2013 09:56:34 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0000A21F9CC2 for ; Tue, 6 Aug 2013 09:56:33 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E0ABDF24085 for ; Tue, 6 Aug 2013 12:57:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id Tcx+nyr8MWIf for ; Tue, 6 Aug 2013 12:56:02 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 790FDF2402A for ; Tue, 6 Aug 2013 12:57:31 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Aug 2013 12:56:30 -0400 Message-Id: <7BBDC0EC-23F0-4DF2-ADB7-A77B6CE8A656@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [stir] Please keep to minute review and charter discussion X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:56:40 -0000 Once we get chartered, we will need to discuss many of these topics, but = I'd like to focus out energy on getting a working group chartered.= From housley@vigilsec.com Tue Aug 6 10:12:59 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C4821F8756 for ; Tue, 6 Aug 2013 10:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLyLI69t1C+4 for ; Tue, 6 Aug 2013 10:12:53 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 48BFE21F9ECA for ; Tue, 6 Aug 2013 10:12:53 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 09A3CF2408D; Tue, 6 Aug 2013 13:12:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id H4DjNjUysFZA; Tue, 6 Aug 2013 13:12:51 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 18609F24085; Tue, 6 Aug 2013 13:12:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <520114D6.2050205@dcrocker.net> Date: Tue, 6 Aug 2013 13:12:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <97FC9B06-AB16-46BE-B46F-B2E9576F0FF2@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> <702EA082-43B7-490D-B909-00630A195CE4@vigilsec.com> <520114D6.2050205@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:12:59 -0000 Dave: >> The threat document is quite different if it cover an in-band = mechanism or both an in-band and an out-of-band mechanism. Do you have = any thoughts on this? Do you have proposed charter text? >=20 > No doubt it's my naivete about the technical side of security work, = but it isn't obvious to me why your assertion is correct. Please = explain the nature of the differences that you see. >=20 > By way of example, imagine an out-of-band mechanism that merely takes = the in-band signature and stashes it somewhere, much like a cookie = mechanism. The storage environment can see the retrieval attributes in = the clear -- the same as any other transit handling node -- I suppose, = but the rest of the information won't be accessible to it. >=20 > Nevermind that, even before we have the charter saying that = out-of-band is to be deferred, we have yet-another introduction of it = into initial technical discussions. The threat environment for in-band is simpler; it contains fewer = entities to consider in the analysis. The threat environment for out-of-band is more complex; it contains all = of the entities in the in-band case as well as SBCs and PSTN entities. Russ From housley@vigilsec.com Tue Aug 6 10:17:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C7921F9FD8 for ; Tue, 6 Aug 2013 10:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVa+ONDVnr1g for ; Tue, 6 Aug 2013 10:17:05 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3846C21F91F4 for ; Tue, 6 Aug 2013 10:17:05 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C6523F2402A; Tue, 6 Aug 2013 13:17:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id K4kaWvbF89Dj; Tue, 6 Aug 2013 13:17:01 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A5903F24085; Tue, 6 Aug 2013 13:17:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> Date: Tue, 6 Aug 2013 13:17:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> To: Lucy Lynch , Steve Kent X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:17:12 -0000 I have gathered the comments that I have seen so far regarding the = privacy paragraph of the charter, and I have updated that paragraph: Authentication and authorization of identity is closely linked to privacy, and these security features frequently come at the cost of privacy. Anonymous calls are already defined in SIP standards, and = this working group will not eliminate this capability. Of course, = anonymous call will not have a valid identity. This working group, to the = extent feasible, will specify privacy-friendly mechanisms do not reveal any = more information to third parties than a call that does not make use of = these mechanisms. I hope this is better than the "punt" that was in the version discussed = at the BOF. Does it capture enough? Does it go to far? Russ On Aug 5, 2013, at 3:44 PM, Russ Housley wrote: > Steve and Lucy: >=20 > I have been thinking about your call for privacy document. >=20 > The privacy document is fairly straight forward if you only consider = the use of a STIR credential in the in-band and an out-of-band = mechanisms. However, it gets much more complicated if one considers = other potential uses (and abuses) of this credential in other protocol = environments. Do you have any thoughts on this? Do you have proposed = charter text? >=20 > Russ From stephen.farrell@cs.tcd.ie Tue Aug 6 10:22:44 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA6221E804D for ; Tue, 6 Aug 2013 10:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn7d3nZjXmU9 for ; Tue, 6 Aug 2013 10:22:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 73D0121F9D34 for ; Tue, 6 Aug 2013 10:22:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D6DCBBE3F; Tue, 6 Aug 2013 18:22:38 +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 Y7tu327yRcGR; Tue, 6 Aug 2013 18:22:37 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.64.202]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 77EC2BE24; Tue, 6 Aug 2013 18:22:37 +0100 (IST) Message-ID: <520130DC.2060705@cs.tcd.ie> Date: Tue, 06 Aug 2013 18:22:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lucy Lynch , IETF STIR Mail List , Steve Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:22:44 -0000 Wordsmithing suggestions below. On 08/06/2013 06:17 PM, Russ Housley wrote: > I have gathered the comments that I have seen so far regarding the privacy paragraph of the charter, and I have updated that paragraph: > > Authentication and authorization of identity is closely linked to > privacy, and these security features frequently come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not eliminate this capability. Of course, anonymous s/anonymous/an anonymous. > call will not have a valid identity. This working group, to the extent s/valid/verifiable/ (anon is "valid" but you just can't check it really) > feasible, will specify privacy-friendly mechanisms do not reveal any more s/do/that do/ > information to third parties than a call that does not make use of these > mechanisms. "extent feasible" is a bit of a punt still though, since we know that the signature and the TN are likely to allow a verifier to infer more about the caller's service provider(s) than just the TN. But I'd be ok with it, S. > > I hope this is better than the "punt" that was in the version discussed at the BOF. > > Does it capture enough? Does it go to far? > > Russ > > > On Aug 5, 2013, at 3:44 PM, Russ Housley wrote: > >> Steve and Lucy: >> >> I have been thinking about your call for privacy document. >> >> The privacy document is fairly straight forward if you only consider the use of a STIR credential in the in-band and an out-of-band mechanisms. However, it gets much more complicated if one considers other potential uses (and abuses) of this credential in other protocol environments. Do you have any thoughts on this? Do you have proposed charter text? >> >> Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > From hadriel.kaplan@oracle.com Tue Aug 6 10:29:32 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3043121E8082 for ; Tue, 6 Aug 2013 10:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U98mK0awFBqS for ; Tue, 6 Aug 2013 10:29:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C2DB421F967C for ; Tue, 6 Aug 2013 10:29:26 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76HTN2v028939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 17:29:23 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76HTMGN007652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 17:29:22 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76HTMZf002152; Tue, 6 Aug 2013 17:29:22 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 10:29:22 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7BBDC0EC-23F0-4DF2-ADB7-A77B6CE8A656@vigilsec.com> Date: Tue, 6 Aug 2013 13:29:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7BBDC0EC-23F0-4DF2-ADB7-A77B6CE8A656@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List Subject: Re: [stir] Please keep to minute review and charter discussion X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:29:32 -0000 Afaik, your current charter questions are: Q1) What are the population sizes we expect in the long-term, and what = impact does this have on the charter text? My answer: No impact on charter text. There's a thread on population = sizes, but afaict the answer is "at least medium but possibly BIG". ------------------------- Q2) The privacy document is fairly straight forward if you only consider = the use of a STIR credential in the in-band and an out-of-band = mechanisms. However, it gets much more complicated if one considers = other potential uses (and abuses) of this credential in other protocol = environments. Do you have any thoughts on this? Do you have proposed = charter text? My answer: Something along the lines of what Brian said makes sense, = tempered by Henning's response. (how's that for being cryptic? :) =20 The proposed charter text you just emailed out a minute ago makes sense = to me. ------------------------- Q3) The threat document is quite different if it cover an in-band = mechanism or both an in-band and an out-of-band mechanism. Do you have = any thoughts on this? Do you have proposed charter text? My answer: we do have to enumerate the threats we're concerned with or = not, and having a separate doc makes sense per Steve's referenced BGP = doc. I propose the following charter text, adding milestone of: "Nov 2013 = Submit A document describing threats to the in-band mechanism for = Informational" If we can include the out-of-band threats in that, great - and that = should be our stretch objective - but if we can't then we add another = milestone later. The above milestone description does not preclude = going beyond. ------------------------- Anything else? -hadriel On Aug 6, 2013, at 12:56 PM, Russ Housley wrote: > Once we get chartered, we will need to discuss many of these topics, = but I'd like to focus out energy on getting a working group chartered. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From housley@vigilsec.com Tue Aug 6 10:31:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D3621F9C4F for ; Tue, 6 Aug 2013 10:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDLI3age-6AV for ; Tue, 6 Aug 2013 10:31:43 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 79C5421F9BCA for ; Tue, 6 Aug 2013 10:31:43 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 39472F2408D; Tue, 6 Aug 2013 13:31:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id D+Tor9F9pKnt; Tue, 6 Aug 2013 13:31:33 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 24207F2402A; Tue, 6 Aug 2013 13:31:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 6 Aug 2013 13:31:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0589FB7B-EC25-461A-ABB8-1AB3A872108C@vigilsec.com> References: <7BBDC0EC-23F0-4DF2-ADB7-A77B6CE8A656@vigilsec.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Please keep to minute review and charter discussion X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:31:48 -0000 Yes. During the BOF, Steve Kent said that he would like to see both a threat = model and a privacy analysis as deliverables early in this process. = What do others think? If you support creation of one of these documents, then answer these two = questions. (1) are you willing to help write one of them? (2) are you willing to help review one of them? Russ On Aug 6, 2013, at 1:29 PM, Hadriel Kaplan wrote: >=20 > Afaik, your current charter questions are: >=20 > Q1) What are the population sizes we expect in the long-term, and what = impact does this have on the charter text? >=20 > My answer: No impact on charter text. There's a thread on population = sizes, but afaict the answer is "at least medium but possibly BIG". >=20 >=20 > ------------------------- >=20 > Q2) The privacy document is fairly straight forward if you only = consider the use of a STIR credential in the in-band and an out-of-band = mechanisms. However, it gets much more complicated if one considers = other potential uses (and abuses) of this credential in other protocol = environments. Do you have any thoughts on this? Do you have proposed = charter text? >=20 > My answer: Something along the lines of what Brian said makes sense, = tempered by Henning's response. (how's that for being cryptic? :) =20 > The proposed charter text you just emailed out a minute ago makes = sense to me. >=20 >=20 > ------------------------- >=20 > Q3) The threat document is quite different if it cover an in-band = mechanism or both an in-band and an out-of-band mechanism. Do you have = any thoughts on this? Do you have proposed charter text? >=20 > My answer: we do have to enumerate the threats we're concerned with or = not, and having a separate doc makes sense per Steve's referenced BGP = doc. >=20 > I propose the following charter text, adding milestone of: "Nov 2013 = Submit A document describing threats to the in-band mechanism for = Informational" >=20 > If we can include the out-of-band threats in that, great - and that = should be our stretch objective - but if we can't then we add another = milestone later. The above milestone description does not preclude = going beyond. >=20 > ------------------------- >=20 > Anything else? >=20 > -hadriel >=20 >=20 >=20 > On Aug 6, 2013, at 12:56 PM, Russ Housley = wrote: >=20 >> Once we get chartered, we will need to discuss many of these topics, = but I'd like to focus out energy on getting a working group chartered. >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From hadriel.kaplan@oracle.com Tue Aug 6 10:36:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7C821F9B90 for ; Tue, 6 Aug 2013 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCj9+nanVtF3 for ; Tue, 6 Aug 2013 10:36:41 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C518521E8092 for ; Tue, 6 Aug 2013 10:36:40 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76HadEN004247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 17:36:40 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76Hadm2015634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 17:36:39 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76HacZa016128; Tue, 6 Aug 2013 17:36:39 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 10:36:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <0589FB7B-EC25-461A-ABB8-1AB3A872108C@vigilsec.com> Date: Tue, 6 Aug 2013 13:36:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7BBDC0EC-23F0-4DF2-ADB7-A77B6CE8A656@vigilsec.com> <0589FB7B-EC25-461A-ABB8-1AB3A872108C@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: IETF STIR Mail List Subject: Re: [stir] Please keep to minute review and charter discussion X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:36:48 -0000 On Aug 6, 2013, at 1:31 PM, Russ Housley wrote: > Yes. > During the BOF, Steve Kent said that he would like to see both a = threat model and a privacy analysis as deliverables early in this = process. What do others think? >=20 > If you support creation of one of these documents, then answer these = two questions. > (1) are you willing to help write one of them? Yes but not as main author/editor - I already have two individual drafts = submitted that I need to update, and two more new ones coming to a = theater near you. > (2) are you willing to help review one of them? Yes. -hadriel From ekr@rtfm.com Tue Aug 6 10:38:14 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBC321F9B86 for ; Tue, 6 Aug 2013 10:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.138 X-Spam-Level: X-Spam-Status: No, score=-103.138 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y7fpdjS1KvF for ; Tue, 6 Aug 2013 10:38:09 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0321F8CB0 for ; Tue, 6 Aug 2013 10:38:05 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id 1so388513qee.13 for ; Tue, 06 Aug 2013 10:38:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IDV5zh7y54bAKJSm2bc1z0oMg2ke1Bos/aZGnxLmWzM=; b=dKmdX2CVgHqBtbb5T9gH7WlnpWPmLvP/g9De0ZY4SYcErvIDvjWzAuVu6ubv7nsG75 a0ADNP/BNTA6cS2eqwz6iDAx7wlUi47+SR0VaNG9Qa5EwgetUI7VWvLjFQe3EE4MoUxf CaeHoMMLxzbEhCwCNtQnnqtbXPI/b+828BQnkWDWJT5VvBs50w/NzwP2oh8E4radCHMn GcvwrLdAZJy26V/keHPRVY96X5/FSEa3U/nMo2PALC7P9cmB28PxED7m4tnHSjr2awDk 8sQz4SKQ2UYchqb1+2k7aKxiROioTZyzlp26sAdmRywqGFuNB1VQVc8aJr6e3cV7R4gu 34aQ== X-Gm-Message-State: ALoCoQltOoYo6ITWRMx22w6Oqz7WJPvKWgvjBc+9TOWm7Fch+2pxSJClx6C60Kged1vVgr4AV0ii X-Received: by 10.224.223.202 with SMTP id il10mr4812880qab.87.1375810684834; Tue, 06 Aug 2013 10:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Tue, 6 Aug 2013 10:37:24 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <0589FB7B-EC25-461A-ABB8-1AB3A872108C@vigilsec.com> References: <7BBDC0EC-23F0-4DF2-ADB7-A77B6CE8A656@vigilsec.com> <0589FB7B-EC25-461A-ABB8-1AB3A872108C@vigilsec.com> From: Eric Rescorla Date: Tue, 6 Aug 2013 10:37:24 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=001a11c2318e25d7fe04e34ae387 Cc: IETF STIR Mail List , Hadriel Kaplan Subject: Re: [stir] Please keep to minute review and charter discussion X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:38:15 -0000 --001a11c2318e25d7fe04e34ae387 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 6, 2013 at 10:31 AM, Russ Housley wrote: > Yes. > > During the BOF, Steve Kent said that he would like to see both a threat > model and a privacy analysis as deliverables early in this process. What > do others think? > I mostly agree with Steve. 1. We should do a threat model as an early deliverable. 2. We should attempt to do some initial privacy goals as guidelines early in the process. 3. Once we have more concrete proposals we should do a privacy assessment against the goals in #2. I am willing to help write all of these. -Ekr If you support creation of one of these documents, then answer these two > questions. > (1) are you willing to help write one of them? > (2) are you willing to help review one of them? > > Russ > > > On Aug 6, 2013, at 1:29 PM, Hadriel Kaplan wrote: > > > > > Afaik, your current charter questions are: > > > > Q1) What are the population sizes we expect in the long-term, and what > impact does this have on the charter text? > > > > My answer: No impact on charter text. There's a thread on population > sizes, but afaict the answer is "at least medium but possibly BIG". > > > > > > ------------------------- > > > > Q2) The privacy document is fairly straight forward if you only consider > the use of a STIR credential in the in-band and an out-of-band mechanisms. > However, it gets much more complicated if one considers other potential > uses (and abuses) of this credential in other protocol environments. Do > you have any thoughts on this? Do you have proposed charter text? > > > > My answer: Something along the lines of what Brian said makes sense, > tempered by Henning's response. (how's that for being cryptic? :) > > The proposed charter text you just emailed out a minute ago makes sense > to me. > > > > > > ------------------------- > > > > Q3) The threat document is quite different if it cover an in-band > mechanism or both an in-band and an out-of-band mechanism. Do you have any > thoughts on this? Do you have proposed charter text? > > > > My answer: we do have to enumerate the threats we're concerned with or > not, and having a separate doc makes sense per Steve's referenced BGP doc. > > > > I propose the following charter text, adding milestone of: "Nov 2013 > Submit A document describing threats to the in-band mechanism for > Informational" > > > > If we can include the out-of-band threats in that, great - and that > should be our stretch objective - but if we can't then we add another > milestone later. The above milestone description does not preclude going > beyond. > > > > ------------------------- > > > > Anything else? > > > > -hadriel > > > > > > > > On Aug 6, 2013, at 12:56 PM, Russ Housley wrote: > > > >> Once we get chartered, we will need to discuss many of these topics, > but I'd like to focus out energy on getting a working group chartered. > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --001a11c2318e25d7fe04e34ae387 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 6, 2013 at 10:31 AM, Russ Housley <= ;housley@vigilsec= .com> wrote:
Yes.

During the BOF, Steve Kent said that he would like to see both a threat mod= el and a privacy analysis as deliverables early in this process. =A0What do= others think?

I mostly agree with Stev= e.

1. We should do a threat model as an early deliverable.=
2. We should attempt to do some initial privacy goals as guideli= nes
early in the process.
3. Once we have more concrete= proposals we should do a privacy
assessment against the goals in #2.

I am will= ing to help write all of these.

-Ekr
If you support creation of one of these documents, then answer these two qu= estions.
(1) are you willing to help write one of them?
(2) are you willing to help review one of them?

Russ


On Aug 6, 2013, at 1:29 PM, Hadriel Kaplan wrote:

>
> Afaik, your current charter questions are:
>
> Q1) What are the population sizes we expect in the long-term, and what= impact does this have on the charter text?
>
> My answer: No impact on charter text. There's a thread on populati= on sizes, but afaict the answer is "at least medium but possibly BIG&q= uot;.
>
>
> -------------------------
>
> Q2) The privacy document is fairly straight forward if you only consid= er the use of a STIR credential in the in-band and an out-of-band mechanism= s. =A0However, it gets much more complicated if one considers other potenti= al uses (and abuses) of this credential in other protocol environments. =A0= Do you have any thoughts on this? =A0Do you have proposed charter text?
>
> My answer: Something along the lines of what Brian said makes sense, t= empered by Henning's response. (how's that for being cryptic? :) > The proposed charter text you just emailed out a minute ago makes sens= e to me.
>
>
> -------------------------
>
> Q3) The threat document is quite different if it cover an in-band mech= anism or both an in-band and an out-of-band mechanism. =A0Do you have any t= houghts on this? =A0Do you have proposed charter text?
>
> My answer: we do have to enumerate the threats we're concerned wit= h or not, and having a separate doc makes sense per Steve's referenced = BGP doc.
>
> I propose the following charter text, adding milestone of: "Nov 2= 013 Submit A document describing threats to the in-band mechanism for Infor= mational"
>
> If we can include the out-of-band threats in that, great - and that sh= ould be our stretch objective - but if we can't then we add another mil= estone later. =A0The above milestone description does not preclude going be= yond.
>
> -------------------------
>
> Anything else?
>
> -hadriel
>
>
>
> On Aug 6, 2013, at 12:56 PM, Russ Housley <housley@vigilsec.com> wrote:
>
>> Once we get chartered, we will need to discuss many of these topic= s, but I'd like to focus out energy on getting a working group chartere= d.
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--001a11c2318e25d7fe04e34ae387-- From michael.hammer@yaanatech.com Tue Aug 6 10:39:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAC121F9D45 for ; Tue, 6 Aug 2013 10:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HHi2JQMieEK for ; Tue, 6 Aug 2013 10:39:07 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 76B0721F9B86 for ; Tue, 6 Aug 2013 10:39:07 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 6 Aug 2013 10:39:07 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "richard@shockey.us" Thread-Topic: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? Thread-Index: AQHOksW0ys/iESdphU+DoP74PwWGRpmIccAA Date: Tue, 6 Aug 2013 17:39:06 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC243CF@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2401A@EX2K10MB1.corp.yaanatech.com> <00ca01ce92bd$be2da620$3a88f260$@shockey.us> <6295AE32-3C75-4E09-9D9F-52E7BF9CF797@oracle.com> In-Reply-To: <6295AE32-3C75-4E09-9D9F-52E7BF9CF797@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.237] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_016B_01CE92AA.51A1D8E0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:39:11 -0000 ------=_NextPart_000_016B_01CE92AA.51A1D8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We need to keep focus on support of whitelist capability. Doing black listing has always been a goose chase. SWATing should never be allowed from an anonymous caller. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, August 06, 2013 12:54 PM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? On Aug 6, 2013, at 11:58 AM, "Richard Shockey" wrote: > I'm sorry to harp on this but legitimate use of anonymity > cannot be used to shield criminal fraud. That is of course another problem > but they are interrelated. I'm hoping we'll be ok on that topic. I don't really equate STIR with tracking the bad guys down - I mean even STIR doesn't tell you where they came in from, and truly bad guys would just not sign their stuff using STIR anyway. You can generate all the anonymous calls you want, but even today we can eventually track them down. It's a major PITA because it requires going carrier-by-carrier comparing numerous CDR records and system logs, but it is doable and is actually performed. We've talked about providing something to help track stuff back (the header list of SPIDs idea), but it's kinda orthogonal to the current STIR deliverables. ISTM we can add it as a milestone later if we want to. That one would have some odd privacy implications, and need careful consideration, but I think it's possible to do. > I'm not tracking INSIPID but I'm disturbed that some folks are talking > about modifying its intended use case. We have a very hard time doing things in RAI for purely operational-improvement purposes. We want new features we can sell, instead. (and I include myself in that general problem too) It's ok though - even with a different Session-ID value per domain, but consistent within portions of the domain, will make back-tracking easier. End-to-end Session-ID was never going to avoid having to look at CDR records to back-track, anyway... just reduce how many CDRs you have to look at. It didn't, for example, tell you what carriers the request came in from/through. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_016B_01CE92AA.51A1D8E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw NjE3MzkwNVowIwYJKoZIhvcNAQkEMRYEFAh2FsEWOWwA0w48GNISGJhXTPprMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEADxNvn+reDgHofb5MBkUTdk22YifmawxYdT2cAE9Y cm9BgbUz/+jIK2mSBEaj6MSLEW0bI0V3WX49xn2AsBzY2XtVa7TZtfzEM1M0jDjYWpJF4E3CuY5q iW/a6ZNKTaE9LO4VAZWPWt9hvQnE/jC0fW1xlYEn4tnWesguszumUknQPJrroYNVIubYjrgz5+p8 xwgq8vDa1eEdYLspBKif4h8BXlaFfFMNVGNf79M7JBfxRpn5VCAcrBrNNzNSJ/uZFozlzHFpQ+an I/EwTit2y/eF1KfLvf/4VwCwMGuxC/xJT+4oGSMnDCVf2S5gRDiXdDZPtgVCDecWwpAgEC0bJwAA AAAAAA== ------=_NextPart_000_016B_01CE92AA.51A1D8E0-- From hadriel.kaplan@oracle.com Tue Aug 6 10:42:28 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5A511E80F0 for ; Tue, 6 Aug 2013 10:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMuMeQajdQwr for ; Tue, 6 Aug 2013 10:42:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A59A311E80EC for ; Tue, 6 Aug 2013 10:42:04 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76Hg0Cg010723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 17:42:00 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76HfxYv001003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 17:41:59 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76HfxiW013996; Tue, 6 Aug 2013 17:41:59 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 10:41:58 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <520130DC.2060705@cs.tcd.ie> Date: Tue, 6 Aug 2013 13:41:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9660CBEB-47D3-40FF-B03D-192A30CBCFD9@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <520130DC.2060705@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:42:28 -0000 On Aug 6, 2013, at 1:22 PM, Stephen Farrell = wrote: > "extent feasible" is a bit of a punt still though, since we know that > the signature and the TN are likely to allow a verifier to infer more > about the caller's service provider(s) than just the TN. I agree that *would* be a problem, and I think (hope?) we're all aware = we have to be careful about that, but I get confused about what it has = to do with charter text? Or let me put it another way - enumerating all = applicable privacy considerations in text in a charter won't help. We = need a section for this in the requirements or solutions doc, or a = separate doc for it. Agree? -hadriel From stephen.farrell@cs.tcd.ie Tue Aug 6 10:49:36 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E39C21F9E85 for ; Tue, 6 Aug 2013 10:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Azb+LCG4T3n for ; Tue, 6 Aug 2013 10:49:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5357111E80E9 for ; Tue, 6 Aug 2013 10:49:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 16E2FBE4D; Tue, 6 Aug 2013 18:49:28 +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 WiMqBV+cJYtY; Tue, 6 Aug 2013 18:49:27 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.64.202]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E31EDBE4C; Tue, 6 Aug 2013 18:49:26 +0100 (IST) Message-ID: <5201371C.2000009@cs.tcd.ie> Date: Tue, 06 Aug 2013 18:49:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <520130DC.2060705@cs.tcd.ie> <9660CBEB-47D3-40FF-B03D-192A30CBCFD9@oracle.com> In-Reply-To: <9660CBEB-47D3-40FF-B03D-192A30CBCFD9@oracle.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:49:36 -0000 On 08/06/2013 06:41 PM, Hadriel Kaplan wrote: > > On Aug 6, 2013, at 1:22 PM, Stephen Farrell > wrote: > >> "extent feasible" is a bit of a punt still though, since we know >> that the signature and the TN are likely to allow a verifier to >> infer more about the caller's service provider(s) than just the >> TN. > > I agree that *would* be a problem, and I think (hope?) we're all > aware we have to be careful about that, but I get confused about what > it has to do with charter text? Or let me put it another way - > enumerating all applicable privacy considerations in text in a > charter won't help. We need a section for this in the requirements > or solutions doc, or a separate doc for it. Agree? I agree that enumerating privacy issues in the charter would be a bad plan. Nonetheless, the current text seems to mean "...to the extent feasible (but we know its not really feasible) will specify privacy friendly..." except we've left out the parenthetical. S. > > -hadriel > > _______________________________________________ stir mailing list > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir > From br@brianrosen.net Tue Aug 6 10:52:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D0621E8092 for ; Tue, 6 Aug 2013 10:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.059 X-Spam-Level: X-Spam-Status: No, score=-102.059 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMTnmGdvxpLf for ; Tue, 6 Aug 2013 10:52:31 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3871321E8091 for ; Tue, 6 Aug 2013 10:52:25 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so524516pde.37 for ; Tue, 06 Aug 2013 10:52:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HDMF7m1vY7xK4YVjf5W9Gj0Li+XqK0OVMF0ro2z2Hzc=; b=NCHfhm7XiQJYOtnHRidP0vEg5ZHUjn2uxzdOMEG5x7g429Rv4QLv8mpLZZ2sG0mggF GqNN6y7bF4t5P9qnlXu+QyVgGgUZpN49lqtcC9h30pmkzswh0yY2Vh7/2JmBnYb9vq8N 6VLk0/xpZlttl65Zd8I35AuRg5r1MbmD3C6pYl9Zjl7i/05dWE3vorUMzhthQs1lLKix Edkpa9pLHBelb26vs9qQKjlFfjlUqTYlFA8MB6A2GSe9HC4xXVnQzBOm+FSAmbjKtn8a GI0yC/AhlDvxsTTgt50BbCO1lkpLiIr8WEVNkIE1xFvnvdif3VIoDXjfkw/eN+XUn/lt kRMA== X-Gm-Message-State: ALoCoQlym3gN2GHngEuh9MD7zB1dZs55PP3DeKQjJw7O/mhA7ZCjke1JpjZLie0ToliXxVwmSN0H MIME-Version: 1.0 X-Received: by 10.68.189.72 with SMTP id gg8mr866470pbc.201.1375811543365; Tue, 06 Aug 2013 10:52:23 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Tue, 6 Aug 2013 10:52:23 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <520130DC.2060705@cs.tcd.ie> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <520130DC.2060705@cs.tcd.ie> Date: Tue, 6 Aug 2013 13:52:23 -0400 Message-ID: From: Brian Rosen To: Stephen Farrell Content-Type: multipart/alternative; boundary=e89a8ff1c85e521ece04e34b165b Cc: Lucy Lynch , IETF STIR Mail List , Russ Housley , Steve Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:52:36 -0000 --e89a8ff1c85e521ece04e34b165b Content-Type: text/plain; charset=ISO-8859-1 Instead of "this group will not eliminate this capability", I suggest "no changes to such standards will be proposed". This eliminates a double negative and reinforces that we are not changing the mechanisms at all. Brian On Tuesday, August 6, 2013, Stephen Farrell wrote: > > Wordsmithing suggestions below. > > On 08/06/2013 06:17 PM, Russ Housley wrote: > > I have gathered the comments that I have seen so far regarding the > privacy paragraph of the charter, and I have updated that paragraph: > > > > Authentication and authorization of identity is closely linked to > > privacy, and these security features frequently come at the cost of > > privacy. Anonymous calls are already defined in SIP standards, and > this > > working group will not eliminate this capability. Of course, > anonymous > > s/anonymous/an anonymous. > > > call will not have a valid identity. This working group, to the > extent > > s/valid/verifiable/ (anon is "valid" but you just can't check it really) > > > feasible, will specify privacy-friendly mechanisms do not reveal any > more > > s/do/that do/ > > > information to third parties than a call that does not make use of > these > > mechanisms. > > "extent feasible" is a bit of a punt still though, since we know that > the signature and the TN are likely to allow a verifier to infer more > about the caller's service provider(s) than just the TN. > > But I'd be ok with it, > S. > > > > > > I hope this is better than the "punt" that was in the version discussed > at the BOF. > > > > Does it capture enough? Does it go to far? > > > > Russ > > > > > > On Aug 5, 2013, at 3:44 PM, Russ Housley wrote: > > > >> Steve and Lucy: > >> > >> I have been thinking about your call for privacy document. > >> > >> The privacy document is fairly straight forward if you only consider > the use of a STIR credential in the in-band and an out-of-band mechanisms. > However, it gets much more complicated if one considers other potential > uses (and abuses) of this credential in other protocol environments. Do > you have any thoughts on this? Do you have proposed charter text? > >> > >> Russ > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --e89a8ff1c85e521ece04e34b165b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Instead of "this group will not eliminate this capability", I sug= gest "no changes to such standards will be proposed". =A0This eli= minates a double negative and reinforces that we are not changing the mecha= nisms at all.

Brian

On Tuesday, August 6, 2013, S= tephen Farrell wrote:

Wordsmithing suggestions below.

On 08/06/2013 06:17 PM, Russ Housley wrote:
> I have gathered the comments that I have seen so far regarding the pri= vacy paragraph of the charter, and I have updated that paragraph:
>
> =A0 =A0Authentication and authorization of identity is closely linked = to
> =A0 =A0privacy, and these security features frequently come at the cos= t of
> =A0 =A0privacy. =A0Anonymous calls are already defined in SIP standard= s, and this
> =A0 =A0working group will not eliminate this capability. =A0Of course,= anonymous=A0

s/anonymous/an anonymous.

> =A0 =A0call will not have a valid identity. =A0This working group, to = the extent

s/valid/verifiable/ (anon is "valid" but you just can't check= it really)

> =A0 =A0feasible, will specify privacy-friendly mechanisms do not revea= l any more

s/do/that do/

> =A0 =A0information to third parties than a call that does not make use= of these
> =A0 =A0mechanisms.

"extent feasible" is a bit of a punt still though, since we know = that
the signature and the TN are likely to allow a verifier to infer more
about the caller's service provider(s) than just the TN.

But I'd be ok with it,
S.


>
> I hope this is better than the "punt" that was in the versio= n discussed at the BOF.
>
> Does it capture enough? =A0Does it go to far?
>
> Russ
>
>
> On Aug 5, 2013, at 3:44 PM, Russ Housley wrote:
>
>> Steve and Lucy:
>>
>> I have been thinking about your call for privacy document.
>>
>> The privacy document is fairly straight forward if you only consid= er the use of a STIR credential in the in-band and an out-of-band mechanism= s. =A0However, it gets much more complicated if one considers other potenti= al uses (and abuses) of this credential in other protocol environments. =A0= Do you have any thoughts on this? =A0Do you have proposed charter text?
>>
>> Russ
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>
>
_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir
--e89a8ff1c85e521ece04e34b165b-- From br@brianrosen.net Tue Aug 6 11:02:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F06821F9F5C for ; Tue, 6 Aug 2013 11:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDrpVlA01xKA for ; Tue, 6 Aug 2013 11:02:43 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 18A9721F9E80 for ; Tue, 6 Aug 2013 11:02:31 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 15so531116pdi.11 for ; Tue, 06 Aug 2013 11:02:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0ZN4Z9FSgr4iRkHle2nkPHDm1tbauYg9R9WvRicj5AU=; b=dIoGZZOlMVQYfo2lzb6gAtR/Yoawld1f5tN75tftEyE+n3o/zQDQ7flo/jNGBfU07/ 5J6B69HYjb6TiV0JNGB8XrbIdFzeEahYKtpYm+9/tLBj8CjxKWOrPcAvEFqDlvwLnLNq VzFXjBvM1Tg+KZD3XYhfqK+T3HCM8vdZGGxOX8+Krxv2G59H/dF3BLRQcMOe0hWG002F i6r/wxrrSw2tbhUh5KAKg7g+HLngzZCp+LqEQmhCrcZOhcvMQV37JyJuEAERXXtJLrPy 2S2YDo7rZBZ0uJ3+DGNkJ/idVBnzlw3lfNH/011i+icCasHUwRhFhXI0EE0w9NZ10dMr +42A== X-Gm-Message-State: ALoCoQmUohUyajSOVxAjCKA7gNxe6PJK2HX+i4iWkes0X/XFClzKRFw5NBBJoexUD/cRTRweq7es MIME-Version: 1.0 X-Received: by 10.66.142.5 with SMTP id rs5mr4582339pab.168.1375812146283; Tue, 06 Aug 2013 11:02:26 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Tue, 6 Aug 2013 11:02:26 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC243CF@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2401A@EX2K10MB1.corp.yaanatech.com> <00ca01ce92bd$be2da620$3a88f260$@shockey.us> <6295AE32-3C75-4E09-9D9F-52E7BF9CF797@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC243CF@EX2K10MB1.corp.yaanatech.com> Date: Tue, 6 Aug 2013 14:02:26 -0400 Message-ID: From: Brian Rosen To: Michael Hammer Content-Type: multipart/alternative; boundary=001a11330f2a41d95404e34b3a72 Cc: "stir@ietf.org" , "hadriel.kaplan@oracle.com" , "richard@shockey.us" Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 18:02:48 -0000 --001a11330f2a41d95404e34b3a72 Content-Type: text/plain; charset=ISO-8859-1 We handle anonymous callers now in some countries because in those countries, calls from unintitalized mobiles are allowed to emergency services. The statistics of such capabilities are very poor (one good call in thousands or tens of thousands of calls handled). However, they are still allowed. The general rule for emergency calls is all calls are accepted, always. The source and validity of identity is used to inform the response. It would be unlikely for a full SWAT team to be deployed in such cases, but some response would undoubtedly be dispatched. Brian On Tuesday, August 6, 2013, Michael Hammer wrote: > We need to keep focus on support of whitelist capability. > Doing black listing has always been a goose chase. > > SWATing should never be allowed from an anonymous caller. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] > On Behalf Of > Hadriel Kaplan > Sent: Tuesday, August 06, 2013 12:54 PM > To: Richard Shockey > Cc: stir@ietf.org > Subject: Re: [stir] Legitimate uses of third party Caller ID authorization > / > spoofing for outbound calling - Re: What are we trying to do, and where do > we want to end up? > > > On Aug 6, 2013, at 11:58 AM, "Richard Shockey" > > wrote: > > > I'm sorry to harp on this but legitimate use of anonymity > > cannot be used to shield criminal fraud. That is of course another > problem > > but they are interrelated. > > I'm hoping we'll be ok on that topic. I don't really equate STIR with > tracking the bad guys down - I mean even STIR doesn't tell you where they > came in from, and truly bad guys would just not sign their stuff using STIR > anyway. You can generate all the anonymous calls you want, but even today > we can eventually track them down. It's a major PITA because it requires > going carrier-by-carrier comparing numerous CDR records and system logs, > but > it is doable and is actually performed. > > We've talked about providing something to help track stuff back (the header > list of SPIDs idea), but it's kinda orthogonal to the current STIR > deliverables. ISTM we can add it as a milestone later if we want to. That > one would have some odd privacy implications, and need careful > consideration, but I think it's possible to do. > > > > I'm not tracking INSIPID but I'm disturbed that some folks are talking > > about modifying its intended use case. > > We have a very hard time doing things in RAI for purely > operational-improvement purposes. We want new features we can sell, > instead. (and I include myself in that general problem too) > > It's ok though - even with a different Session-ID value per domain, but > consistent within portions of the domain, will make back-tracking easier. > End-to-end Session-ID was never going to avoid having to look at CDR > records > to back-track, anyway... just reduce how many CDRs you have to look at. It > didn't, for example, tell you what carriers the request came in > from/through. > > -hadriel > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --001a11330f2a41d95404e34b3a72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We handle anonymous callers now in some countries because in those countrie= s, calls from unintitalized mobiles are allowed to emergency services. =A0T= he statistics of such capabilities are very poor (one good call in thousand= s or tens of thousands of calls handled). =A0However, they are still allowe= d. =A0The general rule for emergency calls is all calls are accepted, alway= s. =A0The source and validity of identity is used to inform the response. = =A0It would be unlikely for a full SWAT=A0team to be deployed in such cases= , but some response would undoubtedly be dispatched. =A0

Brian

On Tuesday, August 6, 2013, Michae= l Hammer wrote:
We need to keep focus on= support of whitelist capability.
Doing black listing has always been a goose chase.

SWATing should never be allowed from an anonymous caller.

Mike


-----Original Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of
Hadriel Kaplan
Sent: Tuesday, August 06, 2013 12:54 PM
To: Richard Shockey
Cc: stir@ietf.org
Subject: Re: [stir] Legitimate uses of third party Caller ID authorization = /
spoofing for outbound calling - Re: What are we trying to do, and where do<= br> we want to end up?


On Aug 6, 2013, at 11:58 AM, "Richard Shockey" <richard@shockey.us> wrote:

> I'm sorry to harp on this but legitimate use of anonymity
> cannot be used to shield criminal fraud. =A0 That is of course another=
problem
> but they are interrelated.

I'm hoping we'll be ok on that topic. =A0I don't really equate = STIR with
tracking the bad guys down - I mean even STIR doesn't tell you where th= ey
came in from, and truly bad guys would just not sign their stuff using STIR=
anyway. =A0You can generate all the anonymous calls you want, but even toda= y
we can eventually track them down. =A0It's a major PITA because it requ= ires
going carrier-by-carrier comparing numerous CDR records and system logs, bu= t
it is doable and is actually performed.

We've talked about providing something to help track stuff back (the he= ader
list of SPIDs idea), but it's kinda orthogonal to the current STIR
deliverables. =A0ISTM we can add it as a milestone later if we want to. =A0= That
one would have some odd privacy implications, and need careful
consideration, but I think it's possible to do.


> I'm not tracking INSIPID but I'm disturbed that some folks are= talking
> about modifying its intended use case.

We have a very hard time doing things in RAI for purely
operational-improvement purposes. =A0We want new features we can sell,
instead. (and I include myself in that general problem too)

It's ok though - even with a different Session-ID value per domain, but=
consistent within portions of the domain, will make back-tracking easier. End-to-end Session-ID was never going to avoid having to look at CDR record= s
to back-track, anyway... just reduce how many CDRs you have to look at. =A0= It
didn't, for example, tell you what carriers the request came in
from/through.

-hadriel

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir
--001a11330f2a41d95404e34b3a72-- From hadriel.kaplan@oracle.com Tue Aug 6 12:17:08 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F93121F9E1D for ; Tue, 6 Aug 2013 12:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5DtqMsv5gvb for ; Tue, 6 Aug 2013 12:17:02 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2B621F9B18 for ; Tue, 6 Aug 2013 12:16:54 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76JGpbF026542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 19:16:53 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76JGoNU004342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 19:16:51 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76JGor2010317; Tue, 6 Aug 2013 19:16:50 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 12:16:50 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 6 Aug 2013 15:16:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <520130DC.2060705@cs.tcd.ie> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 19:17:08 -0000 Ummm... well... I didn't want to raise this before because I didn't = think it would affect the charter and anyway this idea is debatable, but = I was going to suggest we might need to update RFC 5379, so that a = priv-value of 'user' removes any new header we end up defining here. = The STIR document would say to not generate one anyway, so we might just = be ok with that and leave 5379 alone. [As an aside, like RFC 3323 for SIP, SS7 supports network-based privacy = service, where the source identity is passed in the message but screened = out by network equipment from being displayed to the called user. (SS7 = has bit flags for this indication in Calling Party Number param) So at = least for the IKES mechanism, which can be used in SS7, we'd want to = have it not generate a STIR header if the bit-flag is set. I was going = to put that in the next rev of IKES.] -hadriel On Aug 6, 2013, at 1:52 PM, Brian Rosen wrote: > Instead of "this group will not eliminate this capability", I suggest = "no changes to such standards will be proposed". This eliminates a = double negative and reinforces that we are not changing the mechanisms = at all. >=20 > Brian >=20 > On Tuesday, August 6, 2013, Stephen Farrell wrote: >=20 > Wordsmithing suggestions below. >=20 > On 08/06/2013 06:17 PM, Russ Housley wrote: > > I have gathered the comments that I have seen so far regarding the = privacy paragraph of the charter, and I have updated that paragraph: > > > > Authentication and authorization of identity is closely linked to > > privacy, and these security features frequently come at the cost = of > > privacy. Anonymous calls are already defined in SIP standards, = and this > > working group will not eliminate this capability. Of course, = anonymous=20 >=20 > s/anonymous/an anonymous. >=20 > > call will not have a valid identity. This working group, to the = extent >=20 > s/valid/verifiable/ (anon is "valid" but you just can't check it = really) >=20 > > feasible, will specify privacy-friendly mechanisms do not reveal = any more >=20 > s/do/that do/ >=20 > > information to third parties than a call that does not make use = of these > > mechanisms. >=20 > "extent feasible" is a bit of a punt still though, since we know that > the signature and the TN are likely to allow a verifier to infer more > about the caller's service provider(s) than just the TN. >=20 > But I'd be ok with it, > S. >=20 >=20 > > > > I hope this is better than the "punt" that was in the version = discussed at the BOF. > > > > Does it capture enough? Does it go to far? > > > > Russ > > > > > > On Aug 5, 2013, at 3:44 PM, Russ Housley wrote: > > > >> Steve and Lucy: > >> > >> I have been thinking about your call for privacy document. > >> > >> The privacy document is fairly straight forward if you only = consider the use of a STIR credential in the in-band and an out-of-band = mechanisms. However, it gets much more complicated if one considers = other potential uses (and abuses) of this credential in other protocol = environments. Do you have any thoughts on this? Do you have proposed = charter text? > >> > >> Russ > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From housley@vigilsec.com Tue Aug 6 12:22:59 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3830911E80D1 for ; Tue, 6 Aug 2013 12:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.684 X-Spam-Level: X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVxkOshEWVV5 for ; Tue, 6 Aug 2013 12:22:53 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id CFEE921F9FF2 for ; Tue, 6 Aug 2013 12:22:52 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 681BBF2408C; Tue, 6 Aug 2013 15:23:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id PiUVJ6GZU7bU; Tue, 6 Aug 2013 15:22:49 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4352AF24085; Tue, 6 Aug 2013 15:23:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-98-225293158 From: Russ Housley In-Reply-To: Date: Tue, 6 Aug 2013 15:22:47 -0400 Message-Id: <0757C942-8E5C-4D78-A0EE-A242CCFEA0A7@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <520130DC.2060705@cs.tcd.ie> To: Brian Rosen X-Mailer: Apple Mail (2.1085) Cc: Lucy Lynch , IETF STIR Mail List , Steve Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 19:23:00 -0000 --Apple-Mail-98-225293158 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii How about: Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. Russ On Aug 6, 2013, at 1:52 PM, Brian Rosen wrote: > Instead of "this group will not eliminate this capability", I suggest = "no changes to such standards will be proposed". This eliminates a = double negative and reinforces that we are not changing the mechanisms = at all. >=20 > Brian >=20 > On Tuesday, August 6, 2013, Stephen Farrell wrote: >=20 > Wordsmithing suggestions below. >=20 > On 08/06/2013 06:17 PM, Russ Housley wrote: > > I have gathered the comments that I have seen so far regarding the = privacy paragraph of the charter, and I have updated that paragraph: > > > > Authentication and authorization of identity is closely linked to > > privacy, and these security features frequently come at the cost = of > > privacy. Anonymous calls are already defined in SIP standards, = and this > > working group will not eliminate this capability. Of course, = anonymous=20 >=20 > s/anonymous/an anonymous. >=20 > > call will not have a valid identity. This working group, to the = extent >=20 > s/valid/verifiable/ (anon is "valid" but you just can't check it = really) >=20 > > feasible, will specify privacy-friendly mechanisms do not reveal = any more >=20 > s/do/that do/ >=20 > > information to third parties than a call that does not make use = of these > > mechanisms. >=20 > "extent feasible" is a bit of a punt still though, since we know that > the signature and the TN are likely to allow a verifier to infer more > about the caller's service provider(s) than just the TN. >=20 > But I'd be ok with it, > S. >=20 >=20 > > > > I hope this is better than the "punt" that was in the version = discussed at the BOF. > > > > Does it capture enough? Does it go to far? > > > > Russ > > > > > > On Aug 5, 2013, at 3:44 PM, Russ Housley wrote: > > > >> Steve and Lucy: > >> > >> I have been thinking about your call for privacy document. > >> > >> The privacy document is fairly straight forward if you only = consider the use of a STIR credential in the in-band and an out-of-band = mechanisms. However, it gets much more complicated if one considers = other potential uses (and abuses) of this credential in other protocol = environments. Do you have any thoughts on this? Do you have proposed = charter text? > >> > >> Russ > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail-98-225293158 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii How about:

Anonymous calls are already defined in SIP standards, and this
working group will not propose changes to these standards.

Russ


On Aug 6, 2013, at 1:52 PM, Brian Rosen wrote:

Instead of "this group will not eliminate this capability", I suggest "no changes to such standards will be proposed".  This eliminates a double negative and reinforces that we are not changing the mechanisms at all.

Brian

On Tuesday, August 6, 2013, Stephen Farrell wrote:

Wordsmithing suggestions below.

On 08/06/2013 06:17 PM, Russ Housley wrote:
> I have gathered the comments that I have seen so far regarding the privacy paragraph of the charter, and I have updated that paragraph:
>
>    Authentication and authorization of identity is closely linked to
>    privacy, and these security features frequently come at the cost of
>    privacy.  Anonymous calls are already defined in SIP standards, and this
>    working group will not eliminate this capability.  Of course, anonymous 

s/anonymous/an anonymous.

>    call will not have a valid identity.  This working group, to the extent

s/valid/verifiable/ (anon is "valid" but you just can't check it really)

>    feasible, will specify privacy-friendly mechanisms do not reveal any more

s/do/that do/

>    information to third parties than a call that does not make use of these
>    mechanisms.

"extent feasible" is a bit of a punt still though, since we know that
the signature and the TN are likely to allow a verifier to infer more
about the caller's service provider(s) than just the TN.

But I'd be ok with it,
S.


>
> I hope this is better than the "punt" that was in the version discussed at the BOF.
>
> Does it capture enough?  Does it go to far?
>
> Russ
>
>
> On Aug 5, 2013, at 3:44 PM, Russ Housley wrote:
>
>> Steve and Lucy:
>>
>> I have been thinking about your call for privacy document.
>>
>> The privacy document is fairly straight forward if you only consider the use of a STIR credential in the in-band and an out-of-band mechanisms.  However, it gets much more complicated if one considers other potential uses (and abuses) of this credential in other protocol environments.  Do you have any thoughts on this?  Do you have proposed charter text?
>>
>> Russ
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>
>
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--Apple-Mail-98-225293158-- From br@brianrosen.net Tue Aug 6 12:28:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CD411E80F8 for ; Tue, 6 Aug 2013 12:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVbCa1LmIbsu for ; Tue, 6 Aug 2013 12:28:40 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 78EF711E80EF for ; Tue, 6 Aug 2013 12:28:40 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf11so1163848pab.24 for ; Tue, 06 Aug 2013 12:28:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=S3/N8nhTcw9nJDQ0ifGtvOT9ScMXtvU8XHaqk/4Sz14=; b=UlubC4n2wMDNV8nPJP1QVxqjV5dny2eThn339ZGEOCB2HA0x7BTQE+xdc7GkWfgRLv LdaBdJ5Wf5JvT8YQjlRQyLoMkX4yDMHoWh4PIIVhN0UlhN03pK5MUvGOtFkjqzf1j0jD dmb+n4WldQ0AoWTqc2qmeeoc8k3otDdUlR4cpVUJHbBNNSOxOireN9ZnyZQSf75GZFj2 7MIJdZB87AeHZCEEOR9XfKKaxSzAS0/GzfSRwLMRuyhAZQTfYhR7MOgFEWBL3sWWV0JE FK1HmI+cA27gdPHe9wJ3jrGyBxFsZJLqBl0xg1Eg058gTMC90D3ZvM9+D+Z2nnMo2rUt 6opw== X-Gm-Message-State: ALoCoQnSao4nwA5oX0BHZztyu11OLxWa4Q+w45iGJYi0bUM89aUaY61aGdN7ceNghjJL0u+QafAC MIME-Version: 1.0 X-Received: by 10.68.224.161 with SMTP id rd1mr3223539pbc.121.1375817320132; Tue, 06 Aug 2013 12:28:40 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Tue, 6 Aug 2013 12:28:40 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <0757C942-8E5C-4D78-A0EE-A242CCFEA0A7@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <520130DC.2060705@cs.tcd.ie> <0757C942-8E5C-4D78-A0EE-A242CCFEA0A7@vigilsec.com> Date: Tue, 6 Aug 2013 15:28:40 -0400 Message-ID: From: Brian Rosen To: Russ Housley Content-Type: multipart/alternative; boundary=e89a8ff24ff6a486f604e34c6ead Cc: Lucy Lynch , IETF STIR Mail List , Steve Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 19:28:45 -0000 --e89a8ff24ff6a486f604e34c6ead Content-Type: text/plain; charset=ISO-8859-1 WFM On Tuesday, August 6, 2013, Russ Housley wrote: > How about: > > Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. > > Russ > > > On Aug 6, 2013, at 1:52 PM, Brian Rosen wrote: > > Instead of "this group will not eliminate this capability", I suggest "no > changes to such standards will be proposed". This eliminates a double > negative and reinforces that we are not changing the mechanisms at all. > > Brian > > On Tuesday, August 6, 2013, Stephen Farrell wrote: > >> >> Wordsmithing suggestions below. >> >> On 08/06/2013 06:17 PM, Russ Housley wrote: >> > I have gathered the comments that I have seen so far regarding the >> privacy paragraph of the charter, and I have updated that paragraph: >> > >> > Authentication and authorization of identity is closely linked to >> > privacy, and these security features frequently come at the cost of >> > privacy. Anonymous calls are already defined in SIP standards, and >> this >> > working group will not eliminate this capability. Of course, >> anonymous >> >> s/anonymous/an anonymous. >> >> > call will not have a valid identity. This working group, to the >> extent >> >> s/valid/verifiable/ (anon is "valid" but you just can't check it really) >> >> > feasible, will specify privacy-friendly mechanisms do not reveal any >> more >> >> s/do/that do/ >> >> > information to third parties than a call that does not make use of >> these >> > mechanisms. >> >> "extent feasible" is a bit of a punt still though, since we know that >> the signature and the TN are likely to allow a verifier to infer more >> about the caller's service provider(s) than just the TN. >> >> But I'd be ok with it, >> S. >> >> >> > >> > I hope this is better than the "punt" that was in the version discussed >> at the BOF. >> > >> > Does it capture enough? Does it go to far? >> > >> > Russ >> > >> > >> > On Aug 5, 2013, at 3:44 PM, Russ Housley wrote: >> > >> >> Steve and Lucy: >> >> >> >> I have been thinking about your call for privacy document. >> >> >> >> The privacy document is fairly straight forward if you only consider >> the use of a STIR credential in the in-band and an out-of-band mechanisms. >> However, it gets much more complicated if one considers other potential >> uses (and abuses) of this credential in other protocol environments. Do >> you have any thoughts on this? Do you have proposed charter text? >> >> >> >> Russ >> > >> > _______________________________________________ >> > stir mailing list >> > stir@ietf.org >> > https://www.ietf.org/mailman/listinfo/stir >> > >> > >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> > > --e89a8ff24ff6a486f604e34c6ead Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable WFM

On Tuesday, August 6, 2013, Russ Housley wrote:
How abo= ut:

Anonymous calls are already defined in SIP standards, a= nd this
working group will not propose changes to these standards= .

Russ


On Aug 6, 2013, at 1:52 PM, Brian Rosen wrote:

Instead of "this group will not eliminate this capability&= quot;, I suggest "no changes to such standards will be proposed".= =A0This eliminates a double negative and reinforces that we are not changi= ng the mechanisms at all.

Brian

On Tuesday, August 6, 2013, S= tephen Farrell wrote:

Wordsmithing suggestions below.

On 08/06/2013 06:17 PM, Russ Housley wrote:
> I have gathered the comments that I have seen so far regarding the pri= vacy paragraph of the charter, and I have updated that paragraph:
>
> =A0 =A0Authentication and authorization of identity is closely linked = to
> =A0 =A0privacy, and these security features frequently come at the cos= t of
> =A0 =A0privacy. =A0Anonymous calls are already defined in SIP standard= s, and this
> =A0 =A0working group will not eliminate this capability. =A0Of course,= anonymous=A0

s/anonymous/an anonymous.

> =A0 =A0call will not have a valid identity. =A0This working group, to = the extent

s/valid/verifiable/ (anon is "valid" but you just can't check= it really)

> =A0 =A0feasible, will specify privacy-friendly mechanisms do not revea= l any more

s/do/that do/

> =A0 =A0information to third parties than a call that does not make use= of these
> =A0 =A0mechanisms.

"extent feasible" is a bit of a punt still though, since we know = that
the signature and the TN are likely to allow a verifier to infer more
about the caller's service provider(s) than just the TN.

But I'd be ok with it,
S.


>
> I hope this is better than the "punt" that was in the versio= n discussed at the BOF.
>
> Does it capture enough? =A0Does it go to far?
>
> Russ
>
>
> On Aug 5, 2013, at 3:44 PM, Russ Housley wrote:
>
>> Steve and Lucy:
>>
>> I have been thinking about your call for privacy document.
>>
>> The privacy document is fairly straight forward if you only consid= er the use of a STIR credential in the in-band and an out-of-band mechanism= s. =A0However, it gets much more complicated if one considers other potenti= al uses (and abuses) of this credential in other protocol environments. =A0= Do you have any thoughts on this? =A0Do you have proposed charter text?
>>
>> Russ
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>
>
_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--e89a8ff24ff6a486f604e34c6ead-- From housley@vigilsec.com Tue Aug 6 12:47:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A517E21F9E22 for ; Tue, 6 Aug 2013 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNv3UJbAA6YX for ; Tue, 6 Aug 2013 12:47:53 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 525D521F9DF6 for ; Tue, 6 Aug 2013 12:47:53 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 2AB56F24091 for ; Tue, 6 Aug 2013 15:48:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id lWm8GdD5H3wF for ; Tue, 6 Aug 2013 15:47:45 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2F43DF2409C for ; Tue, 6 Aug 2013 15:47:29 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Aug 2013 15:46:55 -0400 Message-Id: <4E3AFB6B-692D-46A7-A374-74F14E2AE1C5@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [stir] Next Draft of the Charter -- 6-Aug-2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 19:47:58 -0000 I have tried to take the comments that I have heard to dat into this = draft. Some people that were very vocal prior to the BOF have gone = quiet, so I expect that some people are on holiday. Please review and comment. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D=20 Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir The STIR working group will specify mechanisms that greatly increase confidence in the source telephone number for an incoming call. Since = it has become fairly easy to present an incorrect source telephone number, = a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited = commercial communications), vishing (voicemail hacking, and impersonating banks) = and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or lead = to a return call at premium rates. This working group will define mechanisms that verify the authorization of the calling party to use a particular telephone number. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working = group. To date, however, true validation of the source of SIP calls has not = seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack = of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify a = SIP header-based mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band = mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key and is associated with the one or more telephone numbers. In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a = telephone number without compromising the global delegation scheme. The mechanism must allow parties who are not delegated a telephone number, but are authorized by the entity who is delegated the number, to place calls using the identity. In addition to its priority mechanism work item, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band mechanism. However, the in-band and = the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is = to develop a solution for telephone numbers. The working group will coordinate with the Security Area on credential management. The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments. Authentication and authorization of identity is closely linked to privacy, and these security features frequently come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. Of course, = an anonymous call will not have a verifiable identity. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of these mechanisms. Input to working group discussions shall include: - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks [RFC 3325] - Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) [RFC 4474] - Secure Call Origin Identification [draft-cooper-iab-secure-origin-00] - Secure Origin Identification: Problem Statement, Requirements, and Roadmap [draft-peterson-secure-origin-ps-00] - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-jennings-dispatch-rfc4474bis-00] The working group will deliver the following: - A problem statement detailing the deployment environment and situation that motivate work on secure telephone identity - A threat model for the secure telephone identity mechanisms - A privacy analysis of the secure telephone identity mechanisms - A mechanism document describing the SIP end-to-end with telephone number-based identities=20 - A document describing the credentials required to support telephone number identity authentication - A fallback mechanism to allow out-of-band identity establishment during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit threat model for Informational Nov 2013 Submit in-band mechanism for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Apr 2014 Submit Privacy analysis for Informational Jun 2014 Submit out-of-band mechanism for Proposed Standard From dhc@dcrocker.net Tue Aug 6 13:17:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3F921F9E80 for ; Tue, 6 Aug 2013 13:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEx0L+VmzUGr for ; Tue, 6 Aug 2013 13:17:10 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B205821F9ED2 for ; Tue, 6 Aug 2013 13:17:10 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r76KH4Wl015475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 13:17:07 -0700 Message-ID: <520159BD.1070305@dcrocker.net> Date: Tue, 06 Aug 2013 13:17:01 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <4E3AFB6B-692D-46A7-A374-74F14E2AE1C5@vigilsec.com> In-Reply-To: <4E3AFB6B-692D-46A7-A374-74F14E2AE1C5@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 06 Aug 2013 13:17:07 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Next Draft of the Charter -- 6-Aug-2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 20:17:15 -0000 On 8/6/2013 12:46 PM, Russ Housley wrote: > > The STIR working group will specify mechanisms that greatly increase > confidence in the source telephone number for an incoming call. Replace this first sentence. In its current form: 1) It is purely marketing language, with a tone approaching hype; 2) it guarantees a human outcome that we cannot guarantee; 3) there's actually some evidence that it won't affect confidence at all; 4) it's vague. Let's keep this an engineering exercise, rather than a human attitudes/opinions exercise. So: The STIR working group will specify mechanisms to validate the presented source telephone number for an incoming SIP call. > Since it > has become fairly easy to present an incorrect source telephone number, a > growing set of problems have emerged over the last decade. As with > email, the claimed source identity of a SIP request is not verified, > permitting unauthorized use of the source identity as part of deceptive > and coercive activities, such as robocalling (bulk unsolicited commercial > communications), vishing (voicemail hacking, and impersonating banks) and > swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, use > of an incorrect source telephone number facilitates wire fraud or lead to > a return call at premium rates. This working group will define > mechanisms that verify the authorization of the calling party to use a > particular telephone number. > > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not seen > any appreciable deployment. Several factors contributed to this lack of > success, including: failure of the problem to be seen as critical at the > time; lack of any technical means of producing a proof of authority over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack of > end-to-end SIP session establishment; and inherent operational problems > with a transitive trust model. To make deployment of this solution more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. > > As its priority mechanism work item, the working group will specify a SIP "Priority mechanism work item"? That's rather strange phrasing. Is there something wrong with simpler, more-direct language: The first work item will specify a SIP header-based... > header-based mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, where the session > is established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone number > representation. The working group will consider choices for protecting > identity information and credentials used, but will likely be based on a > digital signature mechanism that covers a set of information in the SIP > header fields, and verification will employ a credential that contains > the public key and is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a telephone > number without compromising the global delegation scheme. > > The mechanism must allow parties who are not delegated a telephone > number, but are authorized by the entity who is delegated the number, to > place calls using the identity. This sentence appears to be wholly redundant with the sentence before it, at the end of the preceding paragraph. > In addition to its priority mechanism work item, the working group will > consider session establishment where there are one or more non-SIP hops, > most likely using an out-of-band mechanism. However, the in-band and the This sounds remarkably as if there has been a basic change from doing in-band first, to doing in-band and out-of-band together, albeit giving "priority" (whatever that means) to in-band. Please revert to the previous clear, simple, and more-typical sequencing. > out-of-band mechanisms should share as much in common as possible, > especially the credentials. The in-band mechanism must be sent to the > IESG for approval and publication prior to the out-of-band mechanism. Which, of course, continues to imply a finesse of how the work is actually done. For example: The in-band-mechanism must be sent to the IESG for approval, before work will begin on the out-of-band mechanism. The project management difference in this wording is fundamental. If there is a group insistence on doing in-band and out-of-band simultaneously -- which is really what this new language implies -- please make the consensus for this explicit. > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is to > develop a solution for telephone numbers. > > The working group will coordinate with the Security Area on credential > management. > > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. > > Authentication and authorization of identity is closely linked to > privacy, and these security features frequently come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. Of course, an > anonymous call will not have a verifiable identity. This working group, > to the extent feasible, will specify privacy-friendly mechanisms that do > not reveal any more information to third parties than a call that does > not make use of these mechanisms. > > Input to working group discussions shall include: > > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] > > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] > > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] > > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] > > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity > > - A threat model for the secure telephone identity mechanisms > > - A privacy analysis of the secure telephone identity mechanisms > > - A mechanism document describing the SIP end-to-end with telephone > number-based identities > > - A document describing the credentials required to support > telephone number identity authentication > > - A fallback mechanism to allow out-of-band identity establishment > during call setup > > Milestones > > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Tue Aug 6 13:18:38 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1222F21F9CB3 for ; Tue, 6 Aug 2013 13:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZOUdCPjOtVg for ; Tue, 6 Aug 2013 13:18:33 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2740821F9D89 for ; Tue, 6 Aug 2013 13:18:33 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r76KITeZ015516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 13:18:32 -0700 Message-ID: <52015A12.4090909@dcrocker.net> Date: Tue, 06 Aug 2013 13:18:26 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> <702EA082-43B7-490D-B909-00630A195CE4@vigilsec.com> <520114D6.2050205@dcrocker.net> <97FC9B06-AB16-46BE-B46F-B2E9576F0FF2@vigilsec.com> In-Reply-To: <97FC9B06-AB16-46BE-B46F-B2E9576F0FF2@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 06 Aug 2013 13:18:32 -0700 (PDT) Cc: IETF STIR Mail List , dcrocker@bbiw.net Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 20:18:38 -0000 On 8/6/2013 10:12 AM, Russ Housley wrote: >>> The threat document is quite different if it cover an in-band >>> mechanism or both an in-band and an out-of-band mechanism. Do >>> you have any thoughts on this? Do you have proposed charter >>> text? >> >> No doubt it's my naivete about the technical side of security work, >> but it isn't obvious to me why your assertion is correct. Please >> explain the nature of the differences that you see. ... > The threat environment for in-band is simpler; it contains fewer > entities to consider in the analysis. > > The threat environment for out-of-band is more complex; it contains > all of the entities in the in-band case as well as SBCs and PSTN > entities. Ah. OK. Thanks. Yet another good reason to defer working on out-of-band until after in-band is complete. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kent@bbn.com Tue Aug 6 13:36:03 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C477721F9E8B for ; Tue, 6 Aug 2013 13:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlkBSCQ7VAkf for ; Tue, 6 Aug 2013 13:35:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3500721F9E67 for ; Tue, 6 Aug 2013 13:35:52 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50710) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V6nyv-000P6f-6K; Tue, 06 Aug 2013 16:35:49 -0400 Message-ID: <52015E25.3000307@bbn.com> Date: Tue, 06 Aug 2013 16:35:49 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> In-Reply-To: <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lucy Lynch , IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 20:36:04 -0000 Russ, I have not worked on proposed charter text, but now that you ask, I'll work on that. Steve ------ On 8/5/13 3:44 PM, Russ Housley wrote: > Steve and Lucy: > > I have been thinking about your call for privacy document. > > The privacy document is fairly straight forward if you only consider the use of a STIR credential in the in-band and an out-of-band mechanisms. However, it gets much more complicated if one considers other potential uses (and abuses) of this credential in other protocol environments. Do you have any thoughts on this? Do you have proposed charter text? > > Russ > > > On Jul 31, 2013, at 10:25 AM, Russ Housley wrote: > >> With the BOF behind us, I think there is one, and only one topic that this mail list should be discussing. That is the charter text that is ready for the IESG. >> >> The pre-BOF charter text is here: http://www.ietf.org/charter/charter-ietf-stir-00-00.txt >> >> I will hold the pen on changes to the charter text. Some people suggested changes during the BOF: >> >> Preamble >> - Remove "deployable" or change it to "rapidly deployable" >> - Add "within call set up time" >> - Add a discussion of a threat model >> - Be clear that the "calling party" is identified by their telephone number >> >> Postamble >> - Can something be said about alignment of incentives? >> >> Privacy >> - We need to do more than punt. >> >> Please propose exact text for any of these topics. I prefer one proposed change per message in a hope to more easily judge consensus. To this end, I will start a thread on the inclusion of an out-of-band mechanism. >> >> Russ > From kent@bbn.com Tue Aug 6 13:47:21 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A970E21F9F2B for ; Tue, 6 Aug 2013 13:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbHNYQ6y3lWT for ; Tue, 6 Aug 2013 13:47:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D99EA21F9ED9 for ; Tue, 6 Aug 2013 13:47:15 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50741) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V6o9t-0004By-H6; Tue, 06 Aug 2013 16:47:09 -0400 Message-ID: <520160CD.5000306@bbn.com> Date: Tue, 06 Aug 2013 16:47:09 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eric Burger References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> In-Reply-To: <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stir@ietf.org, dcrocker@bbiw.net Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 20:47:21 -0000 Eric, I don't think the privacy implications need to be that bad. After all I think we have assumed that callers will still be able to block caller ID info when making a VoIP call, in the same way that *67 works for called initiated on the PSTN. Also, unlisted PSTN numbers, by default, block their caller ID info. Those seem like a reasonable starting point for VoIP caller ID blocking requirements, in the STIR context. > I agree we are not looking at a national security private network analysis. However, we are talking about the potential end of any privacy or anonymity for ANY Internet application, more especially Internet multimedia application. That needs to have a level of analysis that goes beyond either "hopelessly broken" or "don't worry about it." > From pkyzivat@alum.mit.edu Tue Aug 6 13:53:06 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6D221F9EC2 for ; Tue, 6 Aug 2013 13:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+-h6u4HHisf for ; Tue, 6 Aug 2013 13:52:50 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 94F2E21F92B7 for ; Tue, 6 Aug 2013 13:52:49 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta05.westchester.pa.mail.comcast.net with comcast id 9QYp1m00A0Fqzac55YsoSR; Tue, 06 Aug 2013 20:52:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 9Yso1m01F3ZTu2S3UYso7Y; Tue, 06 Aug 2013 20:52:48 +0000 Message-ID: <52016220.9050104@alum.mit.edu> Date: Tue, 06 Aug 2013 22:52:48 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> In-Reply-To: <520160CD.5000306@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375822368; bh=yKCEsNetBMRtxbpLY4mIFmdrash16f37H9FJtvHmGkc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M5Chos3GMUKOtD4cZaDmCEMHkKu960VCMH4I0TsSH4zyx7AhlfOoLzwtFJytJ2VRY a8+zi5aPSRzq5OUt6UmaZk/3CwqvJBb45pxaBEQK4cJN4UvehqkJwTPRYcgxvNUC/I 5QIhkA7T8Lxh4YoO7ekbO5l/53x/ze59L+Y0WyImJhxtoCD2PAeRYsbbEoQY95f+mW PCf0Og1Ju5VcEsBKdSg4tNAbuV07+bDhehB/zF16hoP1/FbzugzqZdX/FWM1JSpGE6 6dSkpGGF6WMgmTeoz6Uy8MJN58q4OXGCBILJ6kkGYgaXpsn3tr+cRo2ErfMbdv/WSs cK9+LQxd/OWBA== Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 20:53:06 -0000 IMO there is a *big* difference between carrying identity info and removing it just before passing to the callee, and never having identity info in call at all. Thanks, Paul On 8/6/13 10:47 PM, Stephen Kent wrote: > Eric, > > I don't think the privacy implications need to be that bad. After all I > think we > have assumed that callers will still be able to block caller ID info when > making a VoIP call, in the same way that *67 works for called initiated > on the PSTN. > Also, unlisted PSTN numbers, by default, block their caller ID info. > > Those seem like a reasonable starting point for VoIP caller ID blocking > requirements, > in the STIR context. > >> I agree we are not looking at a national security private network >> analysis. However, we are talking about the potential end of any >> privacy or anonymity for ANY Internet application, more especially >> Internet multimedia application. That needs to have a level of >> analysis that goes beyond either "hopelessly broken" or "don't worry >> about it." >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From kent@bbn.com Tue Aug 6 14:03:36 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED4F21F9ED2 for ; Tue, 6 Aug 2013 14:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvXuAk8yDwad for ; Tue, 6 Aug 2013 14:03:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id EA54821F9EDB for ; Tue, 6 Aug 2013 14:03:28 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50758) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V6oPf-000PJl-GA; Tue, 06 Aug 2013 17:03:27 -0400 Message-ID: <5201649F.3050701@bbn.com> Date: Tue, 06 Aug 2013 17:03:27 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050603090201090402040603" Cc: Lucy Lynch , IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:03:37 -0000 This is a multi-part message in MIME format. --------------050603090201090402040603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Russ, You provided what seems like reasonable charter text. I have made few edits. *Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not eliminate this capability. A called party will receive an indication that the number of the caller has been blocked, in support of anonymity,**equivalent to what it provided in the PSTN today. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of secure telephone identification mechanisms. * Steve --------------050603090201090402040603 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Russ,

You provided what seems like reasonable charter text. I have made few edits.

Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not eliminate this capability. A called party will receive an indication that the number of the caller has been blocked, in support of anonymity, equivalent to what it provided in the PSTN today. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of secure telephone identification mechanisms.

Steve

--------------050603090201090402040603-- From housley@vigilsec.com Tue Aug 6 14:07:30 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E6121F9EE0 for ; Tue, 6 Aug 2013 14:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.679 X-Spam-Level: X-Spam-Status: No, score=-102.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nVgKaSnCoD3 for ; Tue, 6 Aug 2013 14:07:19 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 59D0621E809B for ; Tue, 6 Aug 2013 14:07:19 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1AF71F2408E; Tue, 6 Aug 2013 17:08:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id ow+uCy8p8nIX; Tue, 6 Aug 2013 17:06:45 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5E7C7F24085; Tue, 6 Aug 2013 17:07:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <520159BD.1070305@dcrocker.net> Date: Tue, 6 Aug 2013 17:07:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3C35ADEB-F181-48B9-92CE-0E524FF1F317@vigilsec.com> References: <4E3AFB6B-692D-46A7-A374-74F14E2AE1C5@vigilsec.com> <520159BD.1070305@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Next Draft of the Charter -- 6-Aug-2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:07:30 -0000 Dave: >> The STIR working group will specify mechanisms that greatly increase >> confidence in the source telephone number for an incoming call. >=20 > Replace this first sentence. >=20 > In its current form: 1) It is purely marketing language, with a tone = approaching hype; 2) it guarantees a human outcome that we cannot = guarantee; 3) there's actually some evidence that it won't affect = confidence at all; 4) it's vague. >=20 > Let's keep this an engineering exercise, rather than a human = attitudes/opinions exercise. >=20 > So: >=20 > The STIR working group will specify mechanisms to validate the = presented source telephone number for an incoming SIP call. How about: The STIR working group will specify mechanisms for the validation of = source telephone number for an incoming call. >=20 >=20 >> Since it >> has become fairly easy to present an incorrect source telephone = number, a >> growing set of problems have emerged over the last decade. As with >> email, the claimed source identity of a SIP request is not verified, >> permitting unauthorized use of the source identity as part of = deceptive >> and coercive activities, such as robocalling (bulk unsolicited = commercial >> communications), vishing (voicemail hacking, and impersonating banks) = and >> swatting (impersonating callers to emergency services to stimulate >> unwarranted large scale law enforcement deployments). In addition, = use >> of an incorrect source telephone number facilitates wire fraud or = lead to >> a return call at premium rates. This working group will define >> mechanisms that verify the authorization of the calling party to use = a >> particular telephone number. >>=20 >> SIP is one of the main VoIP technologies used by parties that want to >> present an incorrect origin, in this context an origin telephone = number. >> Several previous efforts have tried to secure the origins of SIP >> communications, including RFC 3325, RFC 4474, and the VIPR working = group. >> To date, however, true validation of the source of SIP calls has not = seen >> any appreciable deployment. Several factors contributed to this lack = of >> success, including: failure of the problem to be seen as critical at = the >> time; lack of any technical means of producing a proof of authority = over >> telephone numbers; misalignment of the mechanisms proposed by RFC = 4474 >> with the complex deployment environment that has emerged for SIP; = lack of >> end-to-end SIP session establishment; and inherent operational = problems >> with a transitive trust model. To make deployment of this solution = more >> likely, consideration must be given to latency, real-time = performance, >> computational overhead, and administrative overhead for the = legitimate >> call source and all verifiers. >>=20 >> As its priority mechanism work item, the working group will specify a = SIP >=20 > "Priority mechanism work item"? That's rather strange phrasing. >=20 > Is there something wrong with simpler, more-direct language: >=20 > The first work item will specify a SIP header-based... Yes. My take of the discussion is that the group want to write a = problem statement and a threat model before any mechanisms. >> header-based mechanism to verify the originator of a SIP session is >> authorized to use the claimed source telephone number, where the = session >> is established with SIP end to end. This is called an in-band = mechanism. >> The mechanism will use a canonical telephone number representation >> specified by the working group, including any mappings that might be >> needed between the SIP header fields and the canonical telephone = number >> representation. The working group will consider choices for = protecting >> identity information and credentials used, but will likely be based = on a >> digital signature mechanism that covers a set of information in the = SIP >> header fields, and verification will employ a credential that = contains >> the public key and is associated with the one or more telephone = numbers. >> In order to be authoritative, credentials used with this mechanism = will >> be derived from existing telephone number assignment and delegation >> models. That is, when a telephone number or range of telephone = numbers >> is delegated to an entity, relevant credentials will be generated (or >> modified) to reflect such delegation. The mechanism must allow a >> telephone number holder to further delegate and revoke use of a = telephone >> number without compromising the global delegation scheme. >>=20 >> The mechanism must allow parties who are not delegated a telephone >> number, but are authorized by the entity who is delegated the number, = to >> place calls using the identity. >=20 > This sentence appears to be wholly redundant with the sentence before = it, at the end of the preceding paragraph. Agreed. I'll delete it. >> In addition to its priority mechanism work item, the working group = will >> consider session establishment where there are one or more non-SIP = hops, >> most likely using an out-of-band mechanism. However, the in-band and = the >=20 > This sounds remarkably as if there has been a basic change from doing = in-band first, to doing in-band and out-of-band together, albeit giving = "priority" (whatever that means) to in-band. >=20 > Please revert to the previous clear, simple, and more-typical = sequencing. That does not match the discussion on the list. Below are exact words = to the list on the day after the BOF. Many people said they could live = with this approach. ! ! That is, the proposed WG will deliver an in-band mechanism first, and = then ! deliver an out-of-band mechanism. Notice that this does not prevent = the WG ! from working on them at the same time, but ti does speak directly to = the order ! that they will be sent to the IESG. I tried to capture that in the charter text, which includes: ! ! The in-band mechanism must be sent to the IESG for approval and ! publication prior to the out-of-band mechanism. >> out-of-band mechanisms should share as much in common as possible, >> especially the credentials. The in-band mechanism must be sent to = the >> IESG for approval and publication prior to the out-of-band mechanism. >=20 > Which, of course, continues to imply a finesse of how the work is = actually done. For example: >=20 > The in-band-mechanism must be sent to the IESG for approval, = before work will begin on the out-of-band mechanism. >=20 > The project management difference in this wording is fundamental. >=20 > If there is a group insistence on doing in-band and out-of-band = simultaneously -- which is really what this new language implies -- = please make the consensus for this explicit. And, many people supported this difference. >> Expansion of the authorization mechanism to identities using the >> user@domain form deferred since the main focus of the working group = is to >> develop a solution for telephone numbers. >>=20 >> The working group will coordinate with the Security Area on = credential >> management. >>=20 >> The working group will coordinate with other working groups in the = RAI >> Area regarding signaling through existing deployments. >>=20 >> Authentication and authorization of identity is closely linked to >> privacy, and these security features frequently come at the cost of >> privacy. Anonymous calls are already defined in SIP standards, and = this >> working group will not propose changes to these standards. Of = course, an >> anonymous call will not have a verifiable identity. This working = group, >> to the extent feasible, will specify privacy-friendly mechanisms that = do >> not reveal any more information to third parties than a call that = does >> not make use of these mechanisms. >>=20 >> Input to working group discussions shall include: >>=20 >> - Private Extensions to the Session Initiation Protocol (SIP) >> for Asserted Identity within Trusted Networks >> [RFC 3325] >>=20 >> - Enhancements for Authenticated Identity Management in the >> Session Initiation Protocol (SIP) >> [RFC 4474] >>=20 >> - Secure Call Origin Identification >> [draft-cooper-iab-secure-origin-00] >>=20 >> - Secure Origin Identification: Problem Statement, Requirements, >> and Roadmap >> [draft-peterson-secure-origin-ps-00] >>=20 >> - Authenticated Identity Management in the Session Initiation >> Protocol (SIP) >> [draft-jennings-dispatch-rfc4474bis-00] >>=20 >> The working group will deliver the following: >>=20 >> - A problem statement detailing the deployment environment and >> situation that motivate work on secure telephone identity >>=20 >> - A threat model for the secure telephone identity mechanisms >>=20 >> - A privacy analysis of the secure telephone identity mechanisms >>=20 >> - A mechanism document describing the SIP end-to-end with telephone >> number-based identities >>=20 >> - A document describing the credentials required to support >> telephone number identity authentication >>=20 >> - A fallback mechanism to allow out-of-band identity establishment >> during call setup >>=20 >> Milestones >>=20 >> Sep 2013 Submit problem statement for Informational >> Nov 2013 Submit threat model for Informational >> Nov 2013 Submit in-band mechanism for Proposed Standard >> Feb 2014 Submit credential specification for Proposed Standard >> Apr 2014 Submit Privacy analysis for Informational >> Jun 2014 Submit out-of-band mechanism for Proposed Standard Russ From br@brianrosen.net Tue Aug 6 14:11:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD4A21E809A for ; Tue, 6 Aug 2013 14:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.684 X-Spam-Level: X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8YvkEpQhyaS for ; Tue, 6 Aug 2013 14:11:09 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33E21E808E for ; Tue, 6 Aug 2013 14:11:08 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id jh10so1274055pab.17 for ; Tue, 06 Aug 2013 14:11:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tt4pYyrFw/uAopE4Dy/jfNu+J/gYf7pRVslOWUgFv7g=; b=pwjyz0Rv7McENesbHs/vri8FS41WhSWnUmQR0E/NX86ra3ZE5PUOvUHFA3tBUgXwNH 8Xr0TMVuJUSzl31GxICVLBJ8e/GWO1EDPCZQpA0GX1e/SIrjsICcHNrO9XwuPTJ6ffYE jWsRlpUN4dPYA76JmsBMfoYa4Zx0SKEvQrXIM3LqOIxf+TU1yjkjvSbl0fBzg9niFPsF 1iu5/nZIEVLJbtfFGU5gnqUApKKoyzeVGLy+uVg/hjCvAL0Qzvb2biHBUWWa3cXkoerF +LMt2S7Wf3uqONwgbjiOJ6WI5dolSvoSRYkmABdLQ1/pa7STxB51psYwPXorbUb9MHTJ QPEQ== X-Gm-Message-State: ALoCoQneebSgciQWv47u8P5k4hUiE2vf6qt0WFsMXuSDK/dHd1v3NBgUBxgnmidNquHUUizmjOGc MIME-Version: 1.0 X-Received: by 10.66.227.39 with SMTP id rx7mr874256pac.44.1375823466900; Tue, 06 Aug 2013 14:11:06 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Tue, 6 Aug 2013 14:11:06 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <5201649F.3050701@bbn.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> Date: Tue, 6 Aug 2013 17:11:06 -0400 Message-ID: From: Brian Rosen To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b111f3f04c49004e34dddb7 Cc: Lucy Lynch , IETF STIR Mail List , Russ Housley Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:11:15 -0000 --047d7b111f3f04c49004e34dddb7 Content-Type: text/plain; charset=ISO-8859-1 We can't say what a device does when an anonymous call comes or when unauthenticated identity is received. Anonymity in SIP can be stronger than in the PSTN in that the identity is not sent rather than being suppressed at the recipient. We can have suppresssion, at least in some systems as well, but the IETF standards based anonymous call doesn't send any identity. So, I think your suggested addition can't be used. Brian On Tuesday, August 6, 2013, Stephen Kent wrote: > Russ, > > You provided what seems like reasonable charter text. I have made few > edits. > > *Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of privacy. > Anonymous calls are already defined in SIP standards, and this working > group will not eliminate this capability. A called party will receive an > indication that the number of the caller has been blocked, in support of > anonymity,** equivalent to what it provided in the PSTN today. This > working group, to the extent feasible, will specify privacy-friendly > mechanisms that do not reveal any more information to third parties than a > call that does not make use of secure telephone identification mechanisms. > * > > Steve > > --047d7b111f3f04c49004e34dddb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We can't say what a device does when an anonymous call comes or when un= authenticated identity is received. =A0Anonymity in SIP can be stronger tha= n in the PSTN=A0in that the identity is not sent rather than being suppress= ed at the recipient. =A0We can have suppresssion,=A0at least in some system= s as well, but the IETF standards based=A0anonymous call doesn= 't send any identity. =A0 So, I think your suggested addition can't= be used.

Brian

On Tuesday, August 6, 2013, Stephen Kent wrote= :
=20 =20 =20
Russ,

You provided what seems like reasonable charter text. I have made few edits.

Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not eliminate this capability. A called party will receive an indication that the number of the caller has been blocked, in support of anonymity, equivalent to what it provided in the PSTN today. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of secure telephone identification mechanisms.

Steve

--047d7b111f3f04c49004e34dddb7-- From ekr@rtfm.com Tue Aug 6 14:16:27 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354E921F99A2 for ; Tue, 6 Aug 2013 14:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDpFFTQehl1q for ; Tue, 6 Aug 2013 14:16:14 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA1E21F9995 for ; Tue, 6 Aug 2013 14:16:12 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 9so532603qea.7 for ; Tue, 06 Aug 2013 14:16:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OV/wSyzPlm/Q7x54BZVcSVYrMWuoU9oFSN7yteJ2MaQ=; b=TdCysf8qM0gFlu0ehVpzDChJxosxJ+HvDOjYKjubcKWVBKpUqhYh/eFk95c6KHI2Qu Agkl6ZhQ3qxZ21sIZR9eeSMhmAA3XDgC/6fweiUYwzGcfovi/xfRQqdJi8w78p3SgaE+ b22f93De7pOq+EyBXLl7rSyss1lncoT88m1UDOVWx/N+cP+gmzprdsBML3NbbRykeICv F19eKELxvf8YL7yP+JH7UK8J2vgSGDwoPyjhsCKI1XbjpQkliIB3faqqDI1negnF5wLv C8S4mpCq0RCpm8H9RffpBLWEAOBELOnCfCnnldRhAnJu8ofIQzw1ngyaaLa22Guq0AVw R5aQ== X-Gm-Message-State: ALoCoQlomrtHXvnv5/u2QECTCuJn3CmyGykldIK27EOS1FqzkaYuibFDOCZR3EBqd1IyRmGuDnM9 X-Received: by 10.224.47.5 with SMTP id l5mr824802qaf.114.1375823771808; Tue, 06 Aug 2013 14:16:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Tue, 6 Aug 2013 14:15:31 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <520160CD.5000306@bbn.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> From: Eric Rescorla Date: Tue, 6 Aug 2013 14:15:31 -0700 Message-ID: To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11c2c98431474a04e34def69 Cc: "stir@ietf.org" , Dave Crocker Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:16:27 -0000 --001a11c2c98431474a04e34def69 Content-Type: text/plain; charset=ISO-8859-1 I'm not following this either. How would this be the end of privacy for (for instance) Web, any more than it is now.... -Ekr On Tue, Aug 6, 2013 at 1:47 PM, Stephen Kent wrote: > Eric, > > I don't think the privacy implications need to be that bad. After all I > think we > have assumed that callers will still be able to block caller ID info when > making a VoIP call, in the same way that *67 works for called initiated on > the PSTN. > Also, unlisted PSTN numbers, by default, block their caller ID info. > > Those seem like a reasonable starting point for VoIP caller ID blocking > requirements, > in the STIR context. > > > I agree we are not looking at a national security private network >> analysis. However, we are talking about the potential end of any privacy or >> anonymity for ANY Internet application, more especially Internet multimedia >> application. That needs to have a level of analysis that goes beyond either >> "hopelessly broken" or "don't worry about it." >> >> > ______________________________**_________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/**listinfo/stir > --001a11c2c98431474a04e34def69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not following this either. How would this be the e= nd of privacy for
(for instance) Web, any more than it is now....
=

-Ekr



On Tue, Aug 6, 2013 at 1:47 PM, Stephen = Kent <kent@bbn.com> wrote:
Eric,

I don't think the privacy implications need to be that bad. After all I= think we
have assumed that callers will still be able to block caller ID info when making a VoIP call, in the same way that *67 works for called initiated on = the PSTN.
Also, unlisted PSTN numbers, by default, block their caller ID info.

Those seem like a reasonable starting point for VoIP caller ID blocking req= uirements,
in the STIR context.


I agree we are not looking at a national security private network analysis.= However, we are talking about the potential end of any privacy or anonymit= y for ANY Internet application, more especially Internet multimedia applica= tion. That needs to have a level of analysis that goes beyond either "= hopelessly broken" or "don't worry about it."


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--001a11c2c98431474a04e34def69-- From richard@shockey.us Tue Aug 6 14:17:39 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E669C21F9DFB for ; Tue, 6 Aug 2013 14:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.577 X-Spam-Level: X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNmvF0Xo+RMz for ; Tue, 6 Aug 2013 14:17:35 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id E32BB21F991F for ; Tue, 6 Aug 2013 14:17:34 -0700 (PDT) Received: (qmail 20999 invoked by uid 0); 6 Aug 2013 21:17:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.mail.unifiedlayer.com with SMTP; 6 Aug 2013 21:17:12 -0000 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:Date:Subject:In-Reply-To:References:To:From; bh=+VUDWkcOUmBdM2gLng/vwOgEiZlCpW/Z/9UYzvJ0yFs=; b=RxsAJh1/syOtSuPXdGwzKjjLM3nX5YPiNiP/Q6mCbVqaNA7579174I+P/+xF/gZESgYR5AiL1kYX9ROw3GH4PTEhfFq5ERoCbhXxZWhZpsTedXARdLjGzRoXaos2Rafl; Received: from [71.114.100.16] (port=54950 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V6ocy-0000w5-94; Tue, 06 Aug 2013 15:17:12 -0600 From: "Richard Shockey" To: "'Russ Housley'" , References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <520130DC.2060705@cs.tcd.ie> <0757C942-8E5C-4D78-A0EE-A242CCFEA0A7@vigilsec.com> In-Reply-To: <0757C942-8E5C-4D78-A0EE-A242CCFEA0A7@vigilsec.com> Date: Tue, 6 Aug 2013 17:17:10 -0400 Message-ID: <017a01ce92ea$50a8ded0$f1fa9c70$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017B_01CE92C8.C9A0B4B0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQDqwCnHAPUadagDaX2JPwG6BDOBAYI975iYazOlQA== X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:17:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017B_01CE92C8.C9A0B4B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, August 06, 2013 3:23 PM To: Brian Rosen Cc: Lucy Lynch; IETF STIR Mail List; Steve Kent Subject: Re: [stir] Moving from BOF to Charter How about: Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. Russ On Aug 6, 2013, at 1:52 PM, Brian Rosen wrote: Instead of "this group will not eliminate this capability", I suggest "no changes to such standards will be proposed". This eliminates a double negative and reinforces that we are not changing the mechanisms at all. Brian On Tuesday, August 6, 2013, Stephen Farrell wrote: Wordsmithing suggestions below. On 08/06/2013 06:17 PM, Russ Housley wrote: > I have gathered the comments that I have seen so far regarding the privacy paragraph of the charter, and I have updated that paragraph: > > Authentication and authorization of identity is closely linked to > privacy, and these security features frequently come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not eliminate this capability. Of course, anonymous s/anonymous/an anonymous. > call will not have a valid identity. This working group, to the extent s/valid/verifiable/ (anon is "valid" but you just can't check it really) > feasible, will specify privacy-friendly mechanisms do not reveal any more s/do/that do/ > information to third parties than a call that does not make use of these > mechanisms. "extent feasible" is a bit of a punt still though, since we know that the signature and the TN are likely to allow a verifier to infer more about the caller's service provider(s) than just the TN. But I'd be ok with it, S. > > I hope this is better than the "punt" that was in the version discussed at the BOF. > > Does it capture enough? Does it go to far? > > Russ > > > On Aug 5, 2013, at 3:44 PM, Russ Housley wrote: > >> Steve and Lucy: >> >> I have been thinking about your call for privacy document. >> >> The privacy document is fairly straight forward if you only consider the use of a STIR credential in the in-band and an out-of-band mechanisms. However, it gets much more complicated if one considers other potential uses (and abuses) of this credential in other protocol environments. Do you have any thoughts on this? Do you have proposed charter text? >> >> Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_017B_01CE92C8.C9A0B4B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Russ Housley
Sent: Tuesday, August 06, 2013 3:23 = PM
To: Brian Rosen
Cc: Lucy Lynch; IETF STIR Mail = List; Steve Kent
Subject: Re: [stir] Moving from BOF to = Charter

 

How = about:

 

Anonymous calls are already defined in SIP standards, = and this

working group = will not propose changes to these standards.

 

Russ

 

 

On Aug 6, 2013, at 1:52 PM, Brian Rosen = wrote:



Instead of "this group will not eliminate this = capability", I suggest "no changes to such standards will be = proposed".  This eliminates a double negative and reinforces = that we are not changing the mechanisms at all.

 

Brian


On = Tuesday, August 6, 2013, Stephen Farrell = wrote:


Wordsmithing suggestions below.

On = 08/06/2013 06:17 PM, Russ Housley wrote:
> I have gathered the = comments that I have seen so far regarding the privacy paragraph of the = charter, and I have updated that paragraph:
>
>   =  Authentication and authorization of identity is closely linked = to
>    privacy, and these security features frequently = come at the cost of
>    privacy.  Anonymous calls = are already defined in SIP standards, and this
>   =  working group will not eliminate this capability.  Of course, = anonymous 

s/anonymous/an anonymous.

>   =  call will not have a valid identity.  This working group, to = the extent

s/valid/verifiable/ (anon is "valid" but you = just can't check it really)

>    feasible, will = specify privacy-friendly mechanisms do not reveal any = more

s/do/that do/

>    information to third = parties than a call that does not make use of these
>   =  mechanisms.

"extent feasible" is a bit of a punt = still though, since we know that
the signature and the TN are likely = to allow a verifier to infer more
about the caller's service = provider(s) than just the TN.

But I'd be ok with = it,
S.


>
> I hope this is better than the = "punt" that was in the version discussed at the = BOF.
>
> Does it capture enough?  Does it go to = far?
>
> Russ
>
>
> On Aug 5, 2013, at = 3:44 PM, Russ Housley wrote:
>
>> Steve and = Lucy:
>>
>> I have been thinking about your call for = privacy document.
>>
>> The privacy document is fairly = straight forward if you only consider the use of a STIR credential in = the in-band and an out-of-band mechanisms.  However, it gets much = more complicated if one considers other potential uses (and abuses) of = this credential in other protocol environments.  Do you have any = thoughts on this?  Do you have proposed charter = text?
>>
>> Russ
>
> = _______________________________________________
> stir mailing = list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
><= br>>
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 

------=_NextPart_000_017B_01CE92C8.C9A0B4B0-- From michael.hammer@yaanatech.com Tue Aug 6 14:17:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0272521F9E5E for ; Tue, 6 Aug 2013 14:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HalLbvSdnH8 for ; Tue, 6 Aug 2013 14:17:39 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 35B0321F9995 for ; Tue, 6 Aug 2013 14:17:37 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 6 Aug 2013 14:17:37 -0700 From: Michael Hammer To: "kent@bbn.com" , "housley@vigilsec.com" Thread-Topic: [stir] Moving from BOF to Charter Thread-Index: AQHOjfnsWvtGWyhvPke71SQYAe9TS5mHgbMAgAFpOICAAD9EgP//jedA Date: Tue, 6 Aug 2013 21:17:36 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC24A36@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> In-Reply-To: <5201649F.3050701@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.237] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_036D_01CE92C8.D7F97F10" MIME-Version: 1.0 Cc: "lynch@isoc.org" , "stir@ietf.org" Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:17:45 -0000 ------=_NextPart_000_036D_01CE92C8.D7F97F10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_036E_01CE92C8.D7F97F10" ------=_NextPart_001_036E_01CE92C8.D7F97F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would not get into saying what parameters would or would not be provided. Last sentence could mean no new information of any kind. A mechanism with no info is magic. J Could you characterize that as personally identifiable information or similar? Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, August 06, 2013 5:03 PM To: Russ Housley Cc: Lucy Lynch; IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter Russ, You provided what seems like reasonable charter text. I have made few edits. Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not eliminate this capability. A called party will receive an indication that the number of the caller has been blocked, in support of anonymity, equivalent to what it provided in the PSTN today. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of secure telephone identification mechanisms. Steve ------=_NextPart_001_036E_01CE92C8.D7F97F10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would not get into saying what parameters would or would not be = provided.

 

Last sentence could mean no new information of any kind.  =  A mechanism with no info is magic.  J

Could you characterize that as personally identifiable information or = similar?

 

Mike

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Stephen Kent
Sent: Tuesday, August 06, 2013 5:03 = PM
To: Russ Housley
Cc: Lucy Lynch; IETF STIR Mail = List
Subject: Re: [stir] Moving from BOF to = Charter

 

Russ,

You provided what seems like = reasonable charter text. I have made few edits.

Authentication = and authorization of identity is closely linked to privacy, and these = security features sometimes come at the cost of privacy. Anonymous calls = are already defined in SIP standards, and this working group will not = eliminate this capability. A called party will receive an indication = that the number of the caller has been blocked, in support of anonymity, = equivalent to what it provided in the PSTN today. This working group, to = the extent feasible, will specify privacy-friendly mechanisms that do = not reveal any more information to third parties than a call that does = not make use of secure telephone identification mechanisms. =

Steve

------=_NextPart_001_036E_01CE92C8.D7F97F10-- ------=_NextPart_000_036D_01CE92C8.D7F97F10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw NjIxMTczNVowIwYJKoZIhvcNAQkEMRYEFGQrWW13RlXba5JsG5lDOSihSKAmMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAQ4MsiPIDoyNSWPzh0mkXd2ohSCv40GkCWPjxzC49 zoM+luCv5dngHiPTocvHFR2hsjnwF4Tul+5dAlYJXTkeb/DF5keVARudunuhJEYXSa9Y+dk46tKa /0oUhU72YzD14Hs/42XAN8WDOwjz39bsW95zmDGgWhJTQoBKbkPt+oXqnpog//WNqAikuc8qqmfW R8aVMQ2OVEzj5wmi4dPIsYZFQ8wtBwAbLAry+640Qdfdm5JXlmxtUSsCAB4Nm/AHZXAFP+M+Kx7A QUoGuEVghx0PdcrfMpWPzt8772ENgtBTSO/ClYtRXqrkBlY6y8rBS5V8YmS0BFJoqAt3y/KB4gAA AAAAAA== ------=_NextPart_000_036D_01CE92C8.D7F97F10-- From richard@shockey.us Tue Aug 6 14:19:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F2B21F9EC9 for ; Tue, 6 Aug 2013 14:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.916 X-Spam-Level: X-Spam-Status: No, score=-101.916 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qSwEsMecwBi for ; Tue, 6 Aug 2013 14:19:14 -0700 (PDT) Received: from oproxy12-pub.mail.unifiedlayer.com (oproxy12-pub.mail.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 3700A21F9980 for ; Tue, 6 Aug 2013 14:19:14 -0700 (PDT) Received: (qmail 3189 invoked by uid 0); 6 Aug 2013 21:18:52 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.mail.unifiedlayer.com with SMTP; 6 Aug 2013 21:18:52 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=IgoRVJSVgDJB1OzW/3DE9OoCRedhg9ybT1Sr0zFeXLQ=; b=n0qqf2ocDod49zr7kV9547kx32StgzmkegA1ll5hx7YfwMYHhLgxd82leuD4Lvf2QUrPPl31DXzFwJZR8eonCaTyOUyK7ygiTzQ9vD6vQyUmCBnvIW7Eu+SFMpUXIjxI; Received: from [71.114.100.16] (port=54955 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V6oea-0002N1-6R; Tue, 06 Aug 2013 15:18:52 -0600 From: "Richard Shockey" To: , "'Russ Housley'" References: <4E3AFB6B-692D-46A7-A374-74F14E2AE1C5@vigilsec.com> <520159BD.1070305@dcrocker.net> In-Reply-To: <520159BD.1070305@dcrocker.net> Date: Tue, 6 Aug 2013 17:18:49 -0400 Message-ID: <017f01ce92ea$8c3773d0$a4a65b70$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQNCuy+Qvci1ZBFw4jHhzJPK25st2AIQEox6lo/d6PA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: 'IETF STIR Mail List' Subject: Re: [stir] Next Draft of the Charter -- 6-Aug-2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:19:19 -0000 Dave nit picking .. the language is fine with me. Increased confidence is IMHO a goal. We know we do not possess silver bullets. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Tuesday, August 06, 2013 4:17 PM To: Russ Housley Cc: IETF STIR Mail List Subject: Re: [stir] Next Draft of the Charter -- 6-Aug-2013 On 8/6/2013 12:46 PM, Russ Housley wrote: > > The STIR working group will specify mechanisms that greatly increase > confidence in the source telephone number for an incoming call. Replace this first sentence. In its current form: 1) It is purely marketing language, with a tone approaching hype; 2) it guarantees a human outcome that we cannot guarantee; 3) there's actually some evidence that it won't affect confidence at all; 4) it's vague. Let's keep this an engineering exercise, rather than a human attitudes/opinions exercise. So: The STIR working group will specify mechanisms to validate the presented source telephone number for an incoming SIP call. > Since it > has become fairly easy to present an incorrect source telephone number, a > growing set of problems have emerged over the last decade. As with > email, the claimed source identity of a SIP request is not verified, > permitting unauthorized use of the source identity as part of deceptive > and coercive activities, such as robocalling (bulk unsolicited commercial > communications), vishing (voicemail hacking, and impersonating banks) and > swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, use > of an incorrect source telephone number facilitates wire fraud or lead to > a return call at premium rates. This working group will define > mechanisms that verify the authorization of the calling party to use a > particular telephone number. > > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not seen > any appreciable deployment. Several factors contributed to this lack of > success, including: failure of the problem to be seen as critical at the > time; lack of any technical means of producing a proof of authority over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack of > end-to-end SIP session establishment; and inherent operational problems > with a transitive trust model. To make deployment of this solution more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. > > As its priority mechanism work item, the working group will specify a SIP "Priority mechanism work item"? That's rather strange phrasing. Is there something wrong with simpler, more-direct language: The first work item will specify a SIP header-based... > header-based mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, where the session > is established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone number > representation. The working group will consider choices for protecting > identity information and credentials used, but will likely be based on a > digital signature mechanism that covers a set of information in the SIP > header fields, and verification will employ a credential that contains > the public key and is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a telephone > number without compromising the global delegation scheme. > > The mechanism must allow parties who are not delegated a telephone > number, but are authorized by the entity who is delegated the number, to > place calls using the identity. This sentence appears to be wholly redundant with the sentence before it, at the end of the preceding paragraph. > In addition to its priority mechanism work item, the working group will > consider session establishment where there are one or more non-SIP hops, > most likely using an out-of-band mechanism. However, the in-band and the This sounds remarkably as if there has been a basic change from doing in-band first, to doing in-band and out-of-band together, albeit giving "priority" (whatever that means) to in-band. Please revert to the previous clear, simple, and more-typical sequencing. > out-of-band mechanisms should share as much in common as possible, > especially the credentials. The in-band mechanism must be sent to the > IESG for approval and publication prior to the out-of-band mechanism. Which, of course, continues to imply a finesse of how the work is actually done. For example: The in-band-mechanism must be sent to the IESG for approval, before work will begin on the out-of-band mechanism. The project management difference in this wording is fundamental. If there is a group insistence on doing in-band and out-of-band simultaneously -- which is really what this new language implies -- please make the consensus for this explicit. > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is to > develop a solution for telephone numbers. > > The working group will coordinate with the Security Area on credential > management. > > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. > > Authentication and authorization of identity is closely linked to > privacy, and these security features frequently come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. Of course, an > anonymous call will not have a verifiable identity. This working group, > to the extent feasible, will specify privacy-friendly mechanisms that do > not reveal any more information to third parties than a call that does > not make use of these mechanisms. > > Input to working group discussions shall include: > > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] > > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] > > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] > > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] > > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity > > - A threat model for the secure telephone identity mechanisms > > - A privacy analysis of the secure telephone identity mechanisms > > - A mechanism document describing the SIP end-to-end with telephone > number-based identities > > - A document describing the credentials required to support > telephone number identity authentication > > - A fallback mechanism to allow out-of-band identity establishment > during call setup > > Milestones > > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From housley@vigilsec.com Tue Aug 6 14:22:03 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB2C21F9E5B for ; Tue, 6 Aug 2013 14:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd-VZCEtNKGw for ; Tue, 6 Aug 2013 14:21:56 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE5921F9DFB for ; Tue, 6 Aug 2013 14:21:32 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id F3EFAF2408E; Tue, 6 Aug 2013 17:21:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id KWcCcSYtx85V; Tue, 6 Aug 2013 17:21:24 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1A141F24085; Tue, 6 Aug 2013 17:21:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-2-232410435 From: Russ Housley In-Reply-To: <5201649F.3050701@bbn.com> Date: Tue, 6 Aug 2013 17:21:25 -0400 Message-Id: <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1085) Cc: Lucy Lynch , IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:22:03 -0000 --Apple-Mail-2-232410435 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Merging suggestions from other, I come up with: Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. A called party will receive an indication that the source telephone number has been blocked to provide anonymity. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of secure telephone identification mechanisms.=20 Does that work for you? Russ On Aug 6, 2013, at 5:03 PM, Stephen Kent wrote: > Authentication and authorization of identity is closely linked to = privacy, and these security features sometimes come at the cost of = privacy. Anonymous calls are already defined in SIP standards, and this = working group will not eliminate this capability. A called party will = receive an indication that the number of the caller has been blocked, in = support of anonymity, equivalent to what it provided in the PSTN today. = This working group, to the extent feasible, will specify = privacy-friendly mechanisms that do not reveal any more information to = third parties than a call that does not make use of secure telephone = identification mechanisms.=20 --Apple-Mail-2-232410435 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Authentication and authorization of identity is closely = linked to privacy, and these security features sometimes come at the = cost of privacy. Anonymous calls are already defined in SIP standards, = and this working group will not eliminate this capability. A called = party will receive an indication that the number of the caller has been = blocked, in support of anonymity, equivalent to what it = provided in the PSTN today. This working group, to the extent feasible, = will specify privacy-friendly mechanisms that do not reveal any more = information to third parties than a call that does not make use of = secure telephone identification mechanisms. 

= --Apple-Mail-2-232410435-- From jgunn6@csc.com Tue Aug 6 14:24:18 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C9821F9EB0; Tue, 6 Aug 2013 14:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awkJzDfzkz7F; Tue, 6 Aug 2013 14:24:06 -0700 (PDT) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by ietfa.amsl.com (Postfix) with ESMTP id 28F3121F9EB3; Tue, 6 Aug 2013 14:24:00 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-87.messagelabs.com!1375824237!15741249!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22431 invoked from network); 6 Aug 2013 21:23:57 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-14.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Aug 2013 21:23:57 -0000 Received: from amer-gw09.amer.csc.com (cscmail.csc.com [20.6.39.245]) by amer-mta101.csc.com (8.13.8/8.13.8) with ESMTP id r76LK8Bj005334; Tue, 6 Aug 2013 17:20:08 -0400 In-Reply-To: <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> To: Eric Burger MIME-Version: 1.0 X-KeepSent: 5B278904:8500027A-85257BBF:00753497; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Tue, 6 Aug 2013 17:23:55 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 08/06/2013 05:17:23 PM, Serialize complete at 08/06/2013 05:17:23 PM Content-Type: multipart/alternative; boundary="=_alternative 00758C0685257BBF_=" Cc: stir@ietf.org, dcrocker@bbiw.net, stir-bounces@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:24:19 -0000 This is a multipart message in MIME format. --=_alternative 00758C0685257BBF_= Content-Type: text/plain; charset="US-ASCII" But there may be some national security systems that run on the "public" network and legitimately need to conceal the real "originating number" from BOTH the called party and the internal call records. Janet stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM: > From: Eric Burger > > I agree we are not looking at a national security private network > analysis. However, we are talking about the potential end of any > privacy or anonymity for ANY Internet application, more especially > Internet multimedia application. That needs to have a level of > analysis that goes beyond either "hopelessly broken" or "don't worryabout it." > --=_alternative 00758C0685257BBF_= Content-Type: text/html; charset="US-ASCII" But there may be some national security systems that run on the "public" network and legitimately need to conceal the real "originating number" from BOTH the called party and the internal call records.

Janet

stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM:

> From: Eric Burger <eburger@standardstrack.com>

>
> I agree we are not looking at a national security private network
> analysis. However, we are talking about the potential end of any
> privacy or anonymity for ANY Internet application, more especially
> Internet multimedia application. That needs to have a level of
> analysis that goes beyond either "hopelessly broken" or "don't worryabout it."
>

--=_alternative 00758C0685257BBF_=-- From housley@vigilsec.com Tue Aug 6 14:27:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E66121F9CF5 for ; Tue, 6 Aug 2013 14:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.673 X-Spam-Level: X-Spam-Status: No, score=-102.673 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC7CI50r6y-c for ; Tue, 6 Aug 2013 14:27:19 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 00F7321F9EDD for ; Tue, 6 Aug 2013 14:27:16 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8F060F2408C; Tue, 6 Aug 2013 17:27:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id Gz5kKxHVtNW9; Tue, 6 Aug 2013 17:27:03 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id EF8B4F24085; Tue, 6 Aug 2013 17:27:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-4-232758139 From: Russ Housley In-Reply-To: Date: Tue, 6 Aug 2013 17:27:12 -0400 Message-Id: <80B374A5-FEA8-4722-8CC0-277C4CEE90FC@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> To: Janet P Gunn X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:27:24 -0000 --Apple-Mail-4-232758139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Janet: What change to the charter text is needed? Russ On Aug 6, 2013, at 5:23 PM, Janet P Gunn wrote: > But there may be some national security systems that run on the = "public" network and legitimately need to conceal the real "originating = number" from BOTH the called party and the internal call records.=20 >=20 > Janet >=20 >=20 > stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM: >=20 > > From: Eric Burger =20 >=20 > >=20 > > I agree we are not looking at a national security private network=20 > > analysis. However, we are talking about the potential end of any=20 > > privacy or anonymity for ANY Internet application, more especially=20= > > Internet multimedia application. That needs to have a level of=20 > > analysis that goes beyond either "hopelessly broken" or "don't = worryabout it." > >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail-4-232758139 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Janet:

What change to the charter text is needed?

Russ


On Aug 6, 2013, at 5:23 PM, Janet P Gunn wrote:

But there may be some national security systems that run on the "public" network and legitimately need to conceal the real "originating number" from BOTH the called party and the internal call records.

Janet

stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM:

> From: Eric Burger <eburger@standardstrack.com>

>
> I agree we are not looking at a national security private network
> analysis. However, we are talking about the potential end of any
> privacy or anonymity for ANY Internet application, more especially
> Internet multimedia application. That needs to have a level of
> analysis that goes beyond either "hopelessly broken" or "don't worryabout it."
>

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--Apple-Mail-4-232758139-- From kent@bbn.com Tue Aug 6 14:30:07 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739B721F9798 for ; Tue, 6 Aug 2013 14:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiFWtAdhFbCS for ; Tue, 6 Aug 2013 14:30:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6806721F9926 for ; Tue, 6 Aug 2013 14:30:01 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50776) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V6opJ-000Pb8-Ei; Tue, 06 Aug 2013 17:29:57 -0400 Message-ID: <52016AD5.6040306@bbn.com> Date: Tue, 06 Aug 2013 17:29:57 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040505040301010603030203" Cc: Lucy Lynch , IETF STIR Mail List , Russ Housley Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:30:07 -0000 This is a multi-part message in MIME format. --------------040505040301010603030203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, I don't see the term "suppressed" anywhere in my revised text. When I used the "blocked" and made an analogy to PSTN functionality I did not mean that the implementation would be the same, e.g., suppression only to the called party. Steve > We can't say what a device does when an anonymous call comes or when > unauthenticated identity is received. Anonymity in SIP can be > stronger than in the PSTN in that the identity is not sent rather than > being suppressed at the recipient. We can have suppresssion, at least > in some systems as well, but the IETF standards based anonymous call > doesn't send any identity. So, I think your suggested addition can't > be used. > > Brian > > On Tuesday, August 6, 2013, Stephen Kent wrote: > > Russ, > > You provided what seems like reasonable charter text. I have made > few edits. > > *Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and > this working group will not eliminate this capability. A called > party will receive an indication that the number of the caller has > been blocked, in support of anonymity,**equivalent to what it > provided in the PSTN today. This working group, to the extent > feasible, will specify privacy-friendly mechanisms that do not > reveal any more information to third parties than a call that does > not make use of secure telephone identification mechanisms. * > > Steve > --------------040505040301010603030203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

I don't see the term "suppressed" anywhere in my revised text. When I used the
"blocked" and made an analogy to PSTN functionality I did not mean that the
implementation would be the same, e.g., suppression only to the called party.

Steve

We can't say what a device does when an anonymous call comes or when unauthenticated identity is received.  Anonymity in SIP can be stronger than in the PSTN in that the identity is not sent rather than being suppressed at the recipient.  We can have suppresssion, at least in some systems as well, but the IETF standards based anonymous call doesn't send any identity.   So, I think your suggested addition can't be used.

Brian

On Tuesday, August 6, 2013, Stephen Kent wrote:
Russ,

You provided what seems like reasonable charter text. I have made few edits.

Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not eliminate this capability. A called party will receive an indication that the number of the caller has been blocked, in support of anonymity, equivalent to what it provided in the PSTN today. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of secure telephone identification mechanisms.

Steve


--------------040505040301010603030203-- From michael.hammer@yaanatech.com Tue Aug 6 14:34:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59AC21F99DC; Tue, 6 Aug 2013 14:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfJZjfOOaL2G; Tue, 6 Aug 2013 14:34:54 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4C521F9926; Tue, 6 Aug 2013 14:34:54 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 6 Aug 2013 14:34:54 -0700 From: Michael Hammer To: "jgunn6@csc.com" , "eburger@standardstrack.com" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOjgt3HpeE9YPMkUaRYUJB0cUb+pmHkDsAgAGfiYD//40loA== Date: Tue, 6 Aug 2013 21:34:53 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC24B41@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.237] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03F3_01CE92CB.422E4CB0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , "stir-bounces@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:34:59 -0000 ------=_NextPart_000_03F3_01CE92CB.422E4CB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03F4_01CE92CB.422E4CB0" ------=_NextPart_001_03F4_01CE92CB.422E4CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Janet, Couldn't you use fake numbers that could still be signed and pass validation? I think you are saying that the numbers used would not trace back to a given organization, or would trace to storefront.com Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Janet P Gunn Sent: Tuesday, August 06, 2013 5:24 PM To: Eric Burger Cc: stir@ietf.org; dcrocker@bbiw.net; stir-bounces@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) But there may be some national security systems that run on the "public" network and legitimately need to conceal the real "originating number" from BOTH the called party and the internal call records. Janet stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM: > From: Eric Burger > > I agree we are not looking at a national security private network > analysis. However, we are talking about the potential end of any > privacy or anonymity for ANY Internet application, more especially > Internet multimedia application. That needs to have a level of > analysis that goes beyond either "hopelessly broken" or "don't worryabout it." > ------=_NextPart_001_03F4_01CE92CB.422E4CB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Janet,

 

Couldn’t you use fake numbers that could still be signed and = pass validation?

 

I think you are saying that the numbers used would not trace back to = a given organization, or would trace to = storefront.com

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Janet P Gunn
Sent: Tuesday, August 06, 2013 5:24 = PM
To: Eric Burger
Cc: stir@ietf.org; = dcrocker@bbiw.net; stir-bounces@ietf.org
Subject: Re: [stir] = Early Homework (was Re: Moving from BOF to = Charter)

 

But there = may be some national security systems that run on the "public" = network and legitimately need to conceal the real "originating = number" from BOTH the called party and the internal call = records.

Janet


stir-bounces@ietf.org wrote on = 08/05/2013 04:36:40 PM:

> = From: Eric Burger <eburger@standardstrack.com= >

> =
> I agree we are not looking at a national security = private network
> analysis. However, we are talking = about the potential end of any
> privacy or anonymity = for ANY Internet application, more especially
> Internet = multimedia application. That needs to have a level of
> = analysis that goes beyond either "hopelessly broken" or = "don't worryabout it."
> =

------=_NextPart_001_03F4_01CE92CB.422E4CB0-- ------=_NextPart_000_03F3_01CE92CB.422E4CB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw NjIxMzQ1MlowIwYJKoZIhvcNAQkEMRYEFEKeskkd/Uyzw+awzQDFDVr44De5MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAY8M7ZjlV5z9vVRcoF5Ihbim0Ebh8Hfv72peU4fzM en7mhsPIh5R1uxqfuwsnY3TMETplLYOa1fA7F4nfDml2wQu74CpwPJeizbLJCqFH/XvenyJr1/As 6ZPGpVO3lWQ4FaNcUkjls43JLvr8vHNZIr6vJoIV6UB+TpvzAV2XRFMZwg0BPsQLr7XhbhzsWXKR jXMRq8vjlEBNHHFJf1quhCfR4Ymz6UZn2eGZuKGInOMK+9WQjK2QCEeZG/Hw8IatwR9T+tKWU9aX H9N+V4LKNBkJj5xS6Gi9oqCr9IiwZsGXM01wu931frEs2FUNQgAtjlDy0ZnwnXVQIE2CYpv2HAAA AAAAAA== ------=_NextPart_000_03F3_01CE92CB.422E4CB0-- From hadriel.kaplan@oracle.com Tue Aug 6 14:50:13 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5898321F99A2 for ; Tue, 6 Aug 2013 14:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIxpemJe3-fb for ; Tue, 6 Aug 2013 14:49:55 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFBD21F99A8 for ; Tue, 6 Aug 2013 14:49:54 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76LnqRP000707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 21:49:52 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76LnpMQ026837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 21:49:52 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76LnpBa026818; Tue, 6 Aug 2013 21:49:51 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 14:49:51 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <52016220.9050104@alum.mit.edu> Date: Tue, 6 Aug 2013 17:49:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31A9574A-3794-4C36-84B9-AA5D9D48CB06@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <52016220.9050104@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:50:14 -0000 On Aug 6, 2013, at 4:52 PM, Paul Kyzivat wrote: > IMO there is a *big* difference between carrying identity info and = removing it just before passing to the callee, and never having identity = info in call at all. You're right, there is. But we're not affecting that - we're making it = neither worse nor better. SIP already supports both models. Per our = existing SIP Privacy-related RFCs, the originating UA is *always* able = to generate an anonymous From; or it can use a network-based = "anonymization service" if it prefers, again per our RFCs. It can even = do both. Even in deployed SIP networks today, many providers do support letting = the UA generate an anonymous =46rom - it's caused headaches, and I'm not = claiming it's supported by _all_ providers, but many do actually support = it. (I know this from personal experience dealing with its = repercussions, in multiple provider deployments) For the STIR RFCs we generate, I don't think anyone's suggesting the = STIR mechanism would counteract/undo this support, nor that STIR would = generate information about the source identity if the =46rom were = already anonymous. It's technically possible that some people could = screw it up, but I think such errors would be quickly discovered and = fixed. (and at least in the litigious US, they'd probably also be sued = if they didn't fix it) It's technically possible that some people could = purposefully generate STIR info for anonymous calls despite the RFCs, = but they can already generate source identity info today too and ignore = the existing SIP Privacy RFCs. -hadriel From richard@shockey.us Tue Aug 6 14:55:21 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D58521F9CF1 for ; Tue, 6 Aug 2013 14:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.885 X-Spam-Level: X-Spam-Status: No, score=-101.885 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xm0lZki8mZc for ; Tue, 6 Aug 2013 14:55:15 -0700 (PDT) Received: from oproxy5-pub.mail.unifiedlayer.com (oproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 0770E21F99FA for ; Tue, 6 Aug 2013 14:55:06 -0700 (PDT) Received: (qmail 29297 invoked by uid 0); 6 Aug 2013 21:54:39 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy5.mail.unifiedlayer.com with SMTP; 6 Aug 2013 21:54:39 -0000 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:Date:Subject:In-Reply-To:References:Cc:To:From; bh=yUbzLsl9gykz4yrZn74MgHRHtupdVINLn0hUG1P59eo=; b=YOenI4/SGR4PukUsCuQVVzV9kJY50bDfq+BOeKDXB9dmUsw6zPRaRGJIY+524H6coVIoPhS84CNyVwnIsggcDmQNhJAjP81P9cUgtfqLoEcBb2OwAy8+nz7IsJOBUA+S; Received: from [71.114.100.16] (port=55057 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V6pDD-0007Qi-DH; Tue, 06 Aug 2013 15:54:39 -0600 From: "Richard Shockey" To: "'Stephen Kent'" , "'Russ Housley'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> In-Reply-To: <5201649F.3050701@bbn.com> Date: Tue, 6 Aug 2013 17:54:37 -0400 Message-ID: <01c501ce92ef$8c0d3d40$a427b7c0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C6_01CE92CE.05033E60" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQDqwCnHAPUadagCJzGJKZiPMZNw X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: 'Lucy Lynch' , 'IETF STIR Mail List' Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:55:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C6_01CE92CE.05033E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, August 06, 2013 5:03 PM To: Russ Housley Cc: Lucy Lynch; IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter Russ, You provided what seems like reasonable charter text. I have made few edits. Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not eliminate this capability. A called party will receive an indication that the number of the caller has been blocked, in support of anonymity, equivalent to what it provided in the PSTN today. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties [RS> ] or user agents What the network has to see vs what the UA should see. than a call that does not make use of secure telephone identification mechanisms. [RS> ] again let's not get wrapped around the axel here. Steve ------=_NextPart_000_01C6_01CE92CE.05033E60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Stephen Kent
Sent: Tuesday, August 06, 2013 5:03 = PM
To: Russ Housley
Cc: Lucy Lynch; IETF STIR Mail = List
Subject: Re: [stir] Moving from BOF to = Charter

 

Russ,

You provided what seems like = reasonable charter text. I have made few edits.

Authentication = and authorization of identity is closely linked to privacy, and these = security features sometimes come at the cost of privacy. Anonymous calls = are already defined in SIP standards, and this working group will not = eliminate this capability. A called party will receive an indication = that the number of the caller has been blocked, in support of anonymity, = equivalent to what it provided in the PSTN today. This working group, to = the extent feasible, will specify privacy-friendly mechanisms that do = not reveal any more information to third parties

[RS> ] or user agents

What the network has to see vs what the UA should see.  =

 than a call that does not make = use of secure telephone identification mechanisms.

[RS> ]  again let’s not get wrapped around the axel = here.  

 



Steve

<= /html> ------=_NextPart_000_01C6_01CE92CE.05033E60-- From richard@shockey.us Tue Aug 6 14:57:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3003421F9FD8 for ; Tue, 6 Aug 2013 14:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.948 X-Spam-Level: X-Spam-Status: No, score=-101.948 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uqtluh8F0901 for ; Tue, 6 Aug 2013 14:57:41 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 8CB4B21F846E for ; Tue, 6 Aug 2013 14:57:41 -0700 (PDT) Received: (qmail 2141 invoked by uid 0); 6 Aug 2013 21:57:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.mail.unifiedlayer.com with SMTP; 6 Aug 2013 21:57:20 -0000 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:Date:Subject:In-Reply-To:References:Cc:To:From; bh=uR5ffsxwQsW2OLAUPHFn3nEeav72tGtI2y3xjOArHLE=; b=OlVL1OzXPU4sFAsqcj5b5FwPonBhNf4fSKV1+YUQBLghw+7AUbcfyQcff3jz4z2n8xdjtJbpQ0sJC+FqeWEhzTXd+rd99+4yxP2jRysWk8tOy6AMgp1Ldfu/MEVjza5e; Received: from [71.114.100.16] (port=55061 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V6pFn-0001Q2-Az; Tue, 06 Aug 2013 15:57:19 -0600 From: "Richard Shockey" To: "'Janet P Gunn'" , "'Eric Burger'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> In-Reply-To: Date: Tue, 6 Aug 2013 17:57:16 -0400 Message-ID: <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CB_01CE92CE.6450AC90" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAmNFLYoCnpukhgIV32lAmGqcteA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org, dcrocker@bbiw.net, stir-bounces@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:57:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01CB_01CE92CE.6450AC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm curious why would the source be necessary to conceal in the CDR's. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Janet P Gunn Sent: Tuesday, August 06, 2013 5:24 PM To: Eric Burger Cc: stir@ietf.org; dcrocker@bbiw.net; stir-bounces@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) But there may be some national security systems that run on the "public" network and legitimately need to conceal the real "originating number" from BOTH the called party and the internal call records. Janet stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM: > From: Eric Burger > > > I agree we are not looking at a national security private network > analysis. However, we are talking about the potential end of any > privacy or anonymity for ANY Internet application, more especially > Internet multimedia application. That needs to have a level of > analysis that goes beyond either "hopelessly broken" or "don't worryabout it." > ------=_NextPart_000_01CB_01CE92CE.6450AC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m curious why would the source be necessary to conceal in the = CDR’s.  

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Janet P Gunn
Sent: Tuesday, August 06, 2013 5:24 = PM
To: Eric Burger
Cc: stir@ietf.org; = dcrocker@bbiw.net; stir-bounces@ietf.org
Subject: Re: [stir] = Early Homework (was Re: Moving from BOF to = Charter)

 

But there = may be some national security systems that run on the "public" = network and legitimately need to conceal the real "originating = number" from BOTH the called party and the internal call = records.

Janet


stir-bounces@ietf.org wrote on = 08/05/2013 04:36:40 PM:

> = From: Eric Burger <eburger@standardstrack.com= >

> =
> I agree we are not looking at a national security = private network
> analysis. However, we are talking = about the potential end of any
> privacy or anonymity = for ANY Internet application, more especially
> Internet = multimedia application. That needs to have a level of
> = analysis that goes beyond either "hopelessly broken" or = "don't worryabout it."
> =

------=_NextPart_000_01CB_01CE92CE.6450AC90-- From hadriel.kaplan@oracle.com Tue Aug 6 15:00:42 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A08C21F9E39 for ; Tue, 6 Aug 2013 15:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDm9j1IoCcAz for ; Tue, 6 Aug 2013 15:00:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 06F5721F9CD1 for ; Tue, 6 Aug 2013 15:00:36 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76M0YsC028483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 22:00:35 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76M0Y0K001017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 22:00:34 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76M0Yvl019560; Tue, 6 Aug 2013 22:00:34 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 15:00:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 6 Aug 2013 18:00:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> To: Janet P Gunn X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org Mail List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 22:00:42 -0000 Can they conceal it from CDRs now? If so, I don't think what we're = doing will expose it to CDRs. Can you describe how they're doing it, at = even a high-level? I understand if you can't, but just saying it would = help. I've heard of only one way that's done today, and that way won't = be affected by STIR as far as I can tell. Well... when I say "not = affected", I mean it won't cause their real originating numbers to show = up in CDRs, nor in wireshark captures, or system logs, etc. If they can't conceal it from CDRs now, I don't see how it applies to = us. I mean it's not a problem we're tasked with fixing. Can you elaborate on the concern, in any way publicly? -hadriel On Aug 6, 2013, at 5:23 PM, Janet P Gunn wrote: > But there may be some national security systems that run on the = "public" network and legitimately need to conceal the real "originating = number" from BOTH the called party and the internal call records.=20 >=20 > Janet >=20 >=20 > stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM: >=20 > > From: Eric Burger =20 >=20 > >=20 > > I agree we are not looking at a national security private network=20 > > analysis. However, we are talking about the potential end of any=20 > > privacy or anonymity for ANY Internet application, more especially=20= > > Internet multimedia application. That needs to have a level of=20 > > analysis that goes beyond either "hopelessly broken" or "don't = worryabout it." > >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Tue Aug 6 15:02:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5411E80EE for ; Tue, 6 Aug 2013 15:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR1sSNJB5D6k for ; Tue, 6 Aug 2013 15:02:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7378311E80D1 for ; Tue, 6 Aug 2013 15:02:45 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76M2hRX030988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 22:02:44 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76M2hqb001159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 22:02:43 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76M2gH8001143; Tue, 6 Aug 2013 22:02:43 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 15:02:42 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> Date: Tue, 6 Aug 2013 18:02:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> To: "Richard Shockey" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 22:02:51 -0000 Example: an FBI office or agent calls a safe house. -hadriel On Aug 6, 2013, at 5:57 PM, "Richard Shockey" = wrote: > I=92m curious why would the source be necessary to conceal in the = CDR=92s. =20 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Janet P Gunn > Sent: Tuesday, August 06, 2013 5:24 PM > To: Eric Burger > Cc: stir@ietf.org; dcrocker@bbiw.net; stir-bounces@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) > =20 > But there may be some national security systems that run on the = "public" network and legitimately need to conceal the real "originating = number" from BOTH the called party and the internal call records.=20 >=20 > Janet >=20 >=20 > stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM: >=20 > > From: Eric Burger =20 >=20 > >=20 > > I agree we are not looking at a national security private network=20 > > analysis. However, we are talking about the potential end of any=20 > > privacy or anonymity for ANY Internet application, more especially=20= > > Internet multimedia application. That needs to have a level of=20 > > analysis that goes beyond either "hopelessly broken" or "don't = worryabout it." > > >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Tue Aug 6 15:13:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A270A21F9CC2 for ; Tue, 6 Aug 2013 15:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.028 X-Spam-Level: X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4ETHChy4Ocj for ; Tue, 6 Aug 2013 15:13:47 -0700 (PDT) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id CB47E21F9CF5 for ; Tue, 6 Aug 2013 15:13:46 -0700 (PDT) Received: (qmail 30552 invoked by uid 0); 6 Aug 2013 22:13:25 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.mail.unifiedlayer.com with SMTP; 6 Aug 2013 22:13:25 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=Q6iSgrXdDLd0FBX9S6npXChwUDHwUMMx1HX+9H8KgRA=; b=e5BQK4T7VcDLmNvxn0DWQ1WlL+L+2v59coju46HNO0a8tMKHa4b1OkdijyxpSfARWYjP8XU/Alr8TcA3FE+bn7PlZSsmmxHC7ZRBiO95WAytZ1gi+bK3T4nZQ+hMzQu7; Received: from [71.114.100.16] (port=55218 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V6pVN-0006MS-3M; Tue, 06 Aug 2013 16:13:25 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> In-Reply-To: <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> Date: Tue, 6 Aug 2013 18:13:23 -0400 Message-ID: <01e501ce92f2$2b0398c0$810aca40$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAmNFLYoCnpukhgIV32lAAaG2B3cCmQWgJJhIyqJA X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 22:13:51 -0000 OK .. so the FBI or CIA doesn't want the NSA to know who they are calling? Sorry its cocktail hour on the US east coast. I shudder thinking about the corner cases here need to be listed in detail. .... -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, August 06, 2013 6:03 PM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Example: an FBI office or agent calls a safe house. -hadriel On Aug 6, 2013, at 5:57 PM, "Richard Shockey" wrote: > I'm curious why would the source be necessary to conceal in the CDR's. > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Janet P Gunn > Sent: Tuesday, August 06, 2013 5:24 PM > To: Eric Burger > Cc: stir@ietf.org; dcrocker@bbiw.net; stir-bounces@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > But there may be some national security systems that run on the "public" network and legitimately need to conceal the real "originating number" from BOTH the called party and the internal call records. > > Janet > > > stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM: > > > From: Eric Burger > > > > > I agree we are not looking at a national security private network > > analysis. However, we are talking about the potential end of any > > privacy or anonymity for ANY Internet application, more especially > > Internet multimedia application. That needs to have a level of > > analysis that goes beyond either "hopelessly broken" or "don't worryabout it." > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Tue Aug 6 15:22:06 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B27921E80A3 for ; Tue, 6 Aug 2013 15:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.326 X-Spam-Level: X-Spam-Status: No, score=-0.326 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX1fepzKTspA for ; Tue, 6 Aug 2013 15:21:57 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 05E2E11E80F2 for ; Tue, 6 Aug 2013 15:21:56 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id 9Nsn1m00827AodY57aMvwX; Tue, 06 Aug 2013 22:21:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 9aMv1m00f3ZTu2S3faMvsY; Tue, 06 Aug 2013 22:21:55 +0000 Message-ID: <52017703.6090503@alum.mit.edu> Date: Wed, 07 Aug 2013 00:21:55 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <52016220.9050104@alum.mit.edu> <31A9574A-3794-4C36-84B9-AA5D9D48CB06@oracle.com> In-Reply-To: <31A9574A-3794-4C36-84B9-AA5D9D48CB06@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375827715; bh=FuYG01Pb2DP0q7K8zK1mHUv5b0ONosYDAZAD/nWi2mk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kI1qWo9CYu+aqnbX6XnGnrz5arY2h6VS2RPkDss9dEAmffjjx1vEp3imtA/U8ZkzX d9r3GYWYB9SfDmRNThjtcS1ge2wxXJrI6e98VtJS2WYwJQaKSGdAuIy33LCBIi9mXL gSZuZ4nBovmiAC8xYAaAH8fw5PSyG9ig6JNO0rhGGUtES8Y5pN7PxGWaq3obm/MhdE nD8w3IPr6vecn2Yro40vqhgc4OiZhjed7I40E7kPDz/CzPP2q+v8o62/xrEubkYofG yYQWRRnhS3HOW9Ew2pJ38xL+I66DgWoO5fHA8/RusA8salEpQjvtPWAiBn50A2vg4b kKtFuvA9eYnhQ== Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 22:22:06 -0000 Hadriel, I was just responding to Steven's comment, not to the charter. Thanks, Paul On 8/6/13 11:49 PM, Hadriel Kaplan wrote: > > On Aug 6, 2013, at 4:52 PM, Paul Kyzivat wrote: > >> IMO there is a *big* difference between carrying identity info and removing it just before passing to the callee, and never having identity info in call at all. > > You're right, there is. But we're not affecting that - we're making it neither worse nor better. SIP already supports both models. Per our existing SIP Privacy-related RFCs, the originating UA is *always* able to generate an anonymous From; or it can use a network-based "anonymization service" if it prefers, again per our RFCs. It can even do both. > > Even in deployed SIP networks today, many providers do support letting the UA generate an anonymous From - it's caused headaches, and I'm not claiming it's supported by _all_ providers, but many do actually support it. (I know this from personal experience dealing with its repercussions, in multiple provider deployments) > > For the STIR RFCs we generate, I don't think anyone's suggesting the STIR mechanism would counteract/undo this support, nor that STIR would generate information about the source identity if the From were already anonymous. It's technically possible that some people could screw it up, but I think such errors would be quickly discovered and fixed. (and at least in the litigious US, they'd probably also be sued if they didn't fix it) It's technically possible that some people could purposefully generate STIR info for anonymous calls despite the RFCs, but they can already generate source identity info today too and ignore the existing SIP Privacy RFCs. > > -hadriel > > From hadriel.kaplan@oracle.com Tue Aug 6 16:00:30 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334D821E80AB for ; Tue, 6 Aug 2013 16:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eL-0y+PGagM for ; Tue, 6 Aug 2013 16:00:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBFE21F996F for ; Tue, 6 Aug 2013 16:00:23 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76N0Lg2022418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 23:00:22 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76N0KpC024549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 23:00:21 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76N0KjJ005660; Tue, 6 Aug 2013 23:00:20 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 16:00:20 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <01e501ce92f2$2b0398c0$810aca40$@shockey.us> Date: Tue, 6 Aug 2013 19:00:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> <01e501ce92f2$2b0398c0$810aca40$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 23:00:30 -0000 Actually, I always forget which call direction this needs to happen in - = or maybe it needs to happen in both directions. But this is just an = example anyway, of one reason a government might want to hide the real = calling party number from CDRs. I'm not saying it's the primary = use-case, or that it even happens in practice in the real world. It's = just an example people use in public forums such as this, as to why one = needs to be able to hide such things. The issue isn't about the NSA necessarily - the issue is employees at = the carriers along the path. CDRs are viewable by too many employees, = in too many carriers along the call path. Safe houses (places to hide informants/witnesses) are meant to stay safe = and anonymous, obviously - in particular from large criminal = organizations with plenty of money, people, and muscle power. In the = FBI's case, for example, they need to protect safe houses even from = other government organizations they might be investigating/prosecuting. = They have to distrust each other, for good reason. Since you're in DC, = you know this better than me. :) So if you're an FBI office/agent/SAC or whatever, and you need to talk = to the safe house regularly, you don't want to leave a trace in CDRs of = your calling party number... because then someone who knows who the = office/SAC is for a case, and their phone number, can get a hold of CDRs = and look for who that office/SAC is calling, and then figure out the = number to the safe house. Or vice versa, if the Safe House calls the = SAC, the CDRs show calls to the SAC from a safe-house number. (again, I = can't remember which call direction was the one used in the example I'd = heard, or if it's both ways) Once you have potential Safe-House phone = numbers, it's not hard to track down location, since the whole premise = here is you have the money/power to co-opt employees at carriers. Again, I have no idea if this is what really drives the need - it's just = an example I've been told in other public fora. We do similar things for Lawful Intercept, for which the requirements = and mechanisms are publicly known/documented for several countries - not = all countries have the same rules or mechanisms, but they're generally = similar. No CDR entries are recorded/generated about who's under = warrant, being wiretapped past/present/future, etc. If you looked at a = CDR for a wiretapped call, nothing would appear different from a regular = call. -hadriel On Aug 6, 2013, at 6:13 PM, Richard Shockey wrote: >=20 > OK .. so the FBI or CIA doesn't want the NSA to know who they are = calling?=20 >=20 > Sorry its cocktail hour on the US east coast. >=20 > I shudder thinking about the corner cases here need to be listed in = detail. > .... =20 >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 > Sent: Tuesday, August 06, 2013 6:03 PM > To: Richard Shockey > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) >=20 >=20 > Example: an FBI office or agent calls a safe house. >=20 > -hadriel >=20 From philippe.fouquart@orange.com Wed Aug 7 00:57:07 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8733B11E80E6 for ; Wed, 7 Aug 2013 00:57:07 -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=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9bOBGHYDDCK for ; Wed, 7 Aug 2013 00:57:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7D11E810B for ; Wed, 7 Aug 2013 00:57:02 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 79CA818CC58; Wed, 7 Aug 2013 09:57:01 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5D5B227C057; Wed, 7 Aug 2013 09:57:01 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 09:57:01 +0200 From: To: Russ Housley Thread-Topic: [stir] IETF 87 STIR BOF Minutes Thread-Index: AQHOkhJ3Q89rev+4nEyMJzg1HFHb65mH7MoQgABQnQCAASCY0A== Date: Wed, 7 Aug 2013 07:57:01 +0000 Message-ID: <6298_1375862221_5201FDCD_6298_1034_1_B5939C6860701C49AA39C5DA5189448B0B7923@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <8BE71738-46A3-4462-AE74-6C1B9CD4389D@vigilsec.com> <29522_1375782099_5200C4D3_29522_3064_1_B5939C6860701C49AA39C5DA5189448B0B76DE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3B73852F-42DD-4350-A83E-04DBB34DBAB6@vigilsec.com> In-Reply-To: <3B73852F-42DD-4350-A83E-04DBB34DBAB6@vigilsec.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.45418 Cc: IETF STIR Mail List Subject: Re: [stir] IETF 87 STIR BOF Minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 07:57:07 -0000 Yes, it does, thanks.=20 Leaving minutes asides, the point was to say that if there's indeed a gener= al pattern worldwide for identity misappropriation as described during the = problem statement discussion, there are also regional/national elements tha= t make one type of impersonation/anonymisation more 'relevant' than others = there (subdelegation, termination rates etc.). The national policies govern= ing these resources are one example of such factors.=20 Thanks again. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Tuesday, August 06, 2013 6:25 PM To: FOUQUART Philippe OLNC/OLN Cc: IETF STIR Mail List Subject: Re: [stir] IETF 87 STIR BOF Minutes Does this capture it? Philipe: At Orange, we have similar problems in countries where we operate. There are variations, and the exact nature of the problem may depend on the national numbering policies and what they permit. On Aug 6, 2013, at 5:41 AM, wrote: > Thanks to the note takers.=20 >=20 > Under slide 23. (search on " if the numbering policies are legal or not") >=20 > Actually national numbering policies per se are always "legal", by constr= uction. I think my intervention was more along the lines of "There are vari= ations, and the exact nature of the problem may depend on the national numb= ering policies and what they permit, or consider "legal" or not, eg suballo= cation." If the former phrase could be changed into the latter, it'd probab= ly be clearer. Thanks. >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= uss Housley > Sent: Monday, August 05, 2013 9:32 PM > To: IETF STIR Mail List > Subject: [stir] IETF 87 STIR BOF Minutes >=20 > http://www.ietf.org/proceedings/87/minutes/minutes-87-stir >=20 > Thanks very much to Jean Mahoney and Olafur Gudmundsson for taking notes. >=20 > I assembled the minutes from these notes and then posted them. Please se= nd any corrections to the mail list. >=20 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ 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 br@brianrosen.net Wed Aug 7 05:41:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726DA21E80FE for ; Wed, 7 Aug 2013 05:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.717 X-Spam-Level: X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTk3qEXZ6tIF for ; Wed, 7 Aug 2013 05:41:34 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA0221F9AF0 for ; Wed, 7 Aug 2013 05:41:34 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so2101734pad.30 for ; Wed, 07 Aug 2013 05:41:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V0nQfWgG3+bNME1bKPSUGO6fUrpvumVsUL61ZUXFs+A=; b=Aktj3XSlyXnM7Ud+/7Et/cVVXqjXoB+ZJAYmPbKZ5VHAT+IkgOWucXEHIafh7RURT8 kRPqmJwG7WO1QR7IUwWjQOSzve5pCHI4ADmkZvLNbj1WHwazEHAA/cTtzKConfDPpzA3 zMTJLHuHJ+9JECfxz2ef6J7oyBFTRjMZWtgg3ChKPpREIOhPJ10F9mekD3HVC4eqrJBc Y7a/dU+dPyraVy8rq8/r3Q2SMOPH+rmO+bb43HwhSa6BMfIX/YRP4UgWYRXLiTbzBHfh Ego2+LINXEnmIoBCzOC+meWMoNke/bav3jAuwDXXrOOcTM7W43+UHueVyQaw7o2wxEJ7 snLw== X-Gm-Message-State: ALoCoQn6BcqsmUp/bV/VcYit31nxthasQAYSz+ov0HEkePuKDXL7TeMjpo3onJoBi6Sn1Zjaa2ww MIME-Version: 1.0 X-Received: by 10.68.212.229 with SMTP id nn5mr488287pbc.44.1375879293967; Wed, 07 Aug 2013 05:41:33 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Wed, 7 Aug 2013 05:41:33 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <017f01ce92ea$8c3773d0$a4a65b70$@shockey.us> References: <4E3AFB6B-692D-46A7-A374-74F14E2AE1C5@vigilsec.com> <520159BD.1070305@dcrocker.net> <017f01ce92ea$8c3773d0$a4a65b70$@shockey.us> Date: Wed, 7 Aug 2013 08:41:33 -0400 Message-ID: From: Brian Rosen To: Richard Shockey Content-Type: multipart/alternative; boundary=e89a8ff1c8ca92346404e35adc96 Cc: IETF STIR Mail List , Russ Housley , "dcrocker@bbiw.net" Subject: Re: [stir] Next Draft of the Charter -- 6-Aug-2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 12:41:40 -0000 --e89a8ff1c8ca92346404e35adc96 Content-Type: text/plain; charset=ISO-8859-1 yah, and i want to get the charter off to the IESG soon. On Tuesday, August 6, 2013, Richard Shockey wrote: > Dave nit picking .. the language is fine with me. Increased confidence is > IMHO a goal. We know we do not possess silver bullets. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Dave > Crocker > Sent: Tuesday, August 06, 2013 4:17 PM > To: Russ Housley > Cc: IETF STIR Mail List > Subject: Re: [stir] Next Draft of the Charter -- 6-Aug-2013 > > On 8/6/2013 12:46 PM, Russ Housley wrote: > > > > The STIR working group will specify mechanisms that greatly increase > > confidence in the source telephone number for an incoming call. > > Replace this first sentence. > > In its current form: 1) It is purely marketing language, with a tone > approaching hype; 2) it guarantees a human outcome that we cannot > guarantee; > 3) there's actually some evidence that it won't affect confidence at all; > 4) > it's vague. > > Let's keep this an engineering exercise, rather than a human > attitudes/opinions exercise. > > So: > > The STIR working group will specify mechanisms to validate the > presented source telephone number for an incoming SIP call. > > > > Since it > > has become fairly easy to present an incorrect source telephone number, a > > growing set of problems have emerged over the last decade. As with > > email, the claimed source identity of a SIP request is not verified, > > permitting unauthorized use of the source identity as part of deceptive > > and coercive activities, such as robocalling (bulk unsolicited commercial > > communications), vishing (voicemail hacking, and impersonating banks) and > > swatting (impersonating callers to emergency services to stimulate > > unwarranted large scale law enforcement deployments). In addition, use > > of an incorrect source telephone number facilitates wire fraud or lead to > > a return call at premium rates. This working group will define > > mechanisms that verify the authorization of the calling party to use a > > particular telephone number. > > > > SIP is one of the main VoIP technologies used by parties that want to > > present an incorrect origin, in this context an origin telephone number. > > Several previous efforts have tried to secure the origins of SIP > > communications, including RFC 3325, RFC 4474, and the VIPR working group. > > To date, however, true validation of the source of SIP calls has not seen > > any appreciable deployment. Several factors contributed to this lack of > > success, including: failure of the problem to be seen as critical at the > > time; lack of any technical means of producing a proof of authority over > > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > > with the complex deployment environment that has emerged for SIP; lack of > > end-to-end SIP session establishment; and inherent operational problems > > with a transitive trust model. To make deployment of this solution more > > likely, consideration must be given to latency, real-time performance, > > computational overhead, and administrative overhead for the legitimate > > call source and all verifiers. > > > > As its priority mechanism work item, the working group will specify a SIP > > "Priority mechanism work item"? That's rather strange phrasing. > > Is there something wrong with simpler, more-direct language: > > The first work item will specify a SIP header-based... > > > > header-based mechanism to verify the originator of a SIP session is > > authorized to use the claimed source telephone number, where the session > > is established with SIP end to end. This is called an in-band mechanism. > > The mechanism will use a canonical telephone number representation > > specified by the working group, including any mappings that might be > > needed between the SIP header fields and the canonical telephone number > > representation. The working group will consider choices for protecting > > identity information and credentials used, but will likely be based on a > > digital signature mechanism that covers a set of information in the SIP > > header fields, and verification will employ a credential that contains > > the public key and is associated with the one or more telephone numbers. > > In order to be authoritative, credentials used with this mechanism will > > be derived from existing telephone number assignment and delegation > > models. That is, when a telephone number or range of telephone numbers > > is delegated to an entity, relevant credentials will be generated (or > > modifi --e89a8ff1c8ca92346404e35adc96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yah, and i want to get the charter off to the IESG soon.
On Tuesday, August 6, 2013, Richard Shockey wrote:
Dave nit picking .. the language is fine with me. =A0Increased confidence i= s
IMHO a goal. =A0We know we do not possess silver bullets.

-----Original Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On= Behalf Of Dave
Crocker
Sent: Tuesday, August 06, 2013 4:17 PM
To: Russ Housley
Cc: IETF STIR Mail List
Subject: Re: [stir] Next Draft of the Charter -- 6-Aug-2013

On 8/6/2013 12:46 PM, Russ Housley wrote:
>
> The STIR working group will specify mechanisms that greatly increase > confidence in the source telephone number for an incoming call.

Replace this first sentence.

In its current form: =A01) It is purely marketing language, with a tone
approaching hype; 2) it guarantees a human outcome that we cannot guarantee= ;
3) there's actually some evidence that it won't affect confidence a= t all; 4)
it's vague.

Let's keep this an engineering exercise, rather than a human
attitudes/opinions exercise.

So:

=A0 =A0 =A0 The STIR working group will specify mechanisms to validate the<= br> presented source telephone number for an incoming SIP call.


> Since it
> has become fairly easy to present an incorrect source telephone number= , a
> growing set of problems have emerged over the last decade. =A0As with<= br> > email, the claimed source identity of a SIP request is not verified, > permitting unauthorized use of the source identity as part of deceptiv= e
> and coercive activities, such as robocalling (bulk unsolicited commerc= ial
> communications), vishing (voicemail hacking, and impersonating banks) = and
> swatting (impersonating callers to emergency services to stimulate
> unwarranted large scale law enforcement deployments). =A0In addition, = use
> of an incorrect source telephone number facilitates wire fraud or lead= to
> a return call at premium rates. =A0This working group will define
> mechanisms that verify the authorization of the calling party to use a=
> particular telephone number.
>
> SIP is one of the main VoIP technologies used by parties that want to<= br> > present an incorrect origin, in this context an origin telephone numbe= r.
> Several previous efforts have tried to secure the origins of SIP
> communications, including RFC 3325, RFC 4474, and the VIPR working gro= up.
> To date, however, true validation of the source of SIP calls has not s= een
> any appreciable deployment. =A0Several factors contributed to this lac= k of
> success, including: failure of the problem to be seen as critical at t= he
> time; lack of any technical means of producing a proof of authority ov= er
> telephone numbers; misalignment of the mechanisms proposed by RFC 4474=
> with the complex deployment environment that has emerged for SIP; lack= of
> end-to-end SIP session establishment; and inherent operational problem= s
> with a transitive trust model. =A0To make deployment of this solution = more
> likely, consideration must be given to latency, real-time performance,=
> computational overhead, and administrative overhead for the legitimate=
> call source and all verifiers.
>
> As its priority mechanism work item, the working group will specify a = SIP

"Priority mechanism work item"? =A0That's rather strange phra= sing.

Is there something wrong with simpler, more-direct language:

=A0 =A0 =A0The first work item will specify a SIP header-based...


> header-based mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, where the sessi= on
> is established with SIP end to end. =A0This is called an in-band mecha= nism.
> The mechanism will use a canonical telephone number representation
> specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone numbe= r
> representation. =A0The working group will consider choices for protect= ing
> identity information and credentials used, but will likely be based on= a
> digital signature mechanism that covers a set of information in the SI= P
> header fields, and verification will employ a credential that contains=
> the public key and is associated with the one or more telephone number= s.
> In order to be authoritative, credentials used with this mechanism wil= l
> be derived from existing telephone number assignment and delegation > models. =A0That is, when a telephone number or range of telephone numb= ers
> is delegated to an entity, relevant credentials will be generated (or<= br> > modifi
--e89a8ff1c8ca92346404e35adc96-- From br@brianrosen.net Wed Aug 7 05:45:44 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACFB21E80FE for ; Wed, 7 Aug 2013 05:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.743 X-Spam-Level: X-Spam-Status: No, score=-102.743 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTQeSXwWBR2P for ; Wed, 7 Aug 2013 05:45:38 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id DCFE421F9808 for ; Wed, 7 Aug 2013 05:45:37 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb10so2123122pad.37 for ; Wed, 07 Aug 2013 05:45:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uDh5gJJkksuKih8zWE2x5YLKl26BFpWMqCcb+Q3bnVM=; b=XFqb1zlKWLyMxUKZo7EB3qfbCtyxbZR9NhUzmNncB7AJCBiWOdgZaSZacjhqQG7gPH ZizBdy1lBqtQv23wmXLuZJah+tNGqyTCWaXyCFURsb6rwc9kum/pXrmHvBLykcdwks27 /bW3vrCTiKakASBSlxfd9yGVSx7V2+cKlONxLIxzNRe2l6lJewBckJhC6/AA40BjyaR7 018mtWYUpkejws6l2sxtxF+NnTN/2jcJankHPSIY5iZfha1ZlXB6l99TbAEoiRr8voWI eqBGlO/ZjZRzcsD3cpVZqy98f7mQ7LI2UPb1wF4TspF4ofOc+IpaLJ5gD1uSGNOrnXEs fIKA== X-Gm-Message-State: ALoCoQmfjgk95nhtWQaBQLOHTItIzBdihBk6V4kkALgj5jbonC8lxC3EibVCT404FK8IiHoedUFS MIME-Version: 1.0 X-Received: by 10.68.223.225 with SMTP id qx1mr351427pbc.157.1375879536640; Wed, 07 Aug 2013 05:45:36 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Wed, 7 Aug 2013 05:45:36 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <52016AD5.6040306@bbn.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <52016AD5.6040306@bbn.com> Date: Wed, 7 Aug 2013 08:45:36 -0400 Message-ID: From: Brian Rosen To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b16051509199604e35aebd4 Cc: Lucy Lynch , IETF STIR Mail List , Russ Housley Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 12:45:44 -0000 --047d7b16051509199604e35aebd4 Content-Type: text/plain; charset=ISO-8859-1 I did misunderstand the text you proposed, but I do think there is a difference between "blocked" and "never sent". Are you okay with Russ's latest edits? I am. Brian On Tuesday, August 6, 2013, Stephen Kent wrote: > Brian, > > I don't see the term "suppressed" anywhere in my revised text. When I used > the > "blocked" and made an analogy to PSTN functionality I did not mean that the > implementation would be the same, e.g., suppression only to the called > party. > > Steve > > We can't say what a device does when an anonymous call comes or when > unauthenticated identity is received. Anonymity in SIP can be stronger > than in the PSTN in that the identity is not sent rather than being > suppressed at the recipient. We can have suppresssion, at least in some > systems as well, but the IETF standards based anonymous call doesn't send > any identity. So, I think your suggested addition can't be used. > > Brian > > On Tuesday, August 6, 2013, Stephen Kent wrote: > >> Russ, >> >> You provided what seems like reasonable charter text. I have made few >> edits. >> >> *Authentication and authorization of identity is closely linked to >> privacy, and these security features sometimes come at the cost of privacy. >> Anonymous calls are already defined in SIP standards, and this working >> group will not eliminate this capability. A called party will receive an >> indication that the number of the caller has been blocked, in support of >> anonymity,** equivalent to what it provided in the PSTN today. This >> working group, to the extent feasible, will specify privacy-friendly >> mechanisms that do not reveal any more information to third parties than a >> call that does not make use of secure telephone identification mechanisms. >> * >> >> Steve >> >> > --047d7b16051509199604e35aebd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I did misunderstand the text you proposed, but I do think there is a differ= ence between "blocked" and "never sent". =A0Are you oka= y with Russ's latest edits? =A0I am.

Brian

On Tuesday, August 6, 2013, Stephen Kent wrote:
=20 =20 =20
Brian,

I don't see the term "suppressed" anywhere in my revised = text. When I used the
"blocked" and made an analogy to PSTN functionality I did not= mean that the
implementation would be the same, e.g., suppression only to the called party.

Steve

We can't say what a device does when an a= nonymous call comes or when unauthenticated identity is received. =A0Anonymity in SIP can be stronger than in the PSTN=A0in that the identity is not sent rather than being suppressed at the recipient. =A0We can have suppresssion,=A0at least in some systems as well, but the IETF standards based=A0anonymous call doesn't send any identity. =A0 So, I think your suggested addition can't be used.

Brian

On Tuesday, August 6, 2013, Stephen Kent wrote:
Russ,

You provided what seems like reasonable charter text. I have made few edits.

Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not eliminate this capability. A called party will receive an indication that the number of the caller has been blocked, in support of anonymity, equivalent to what it provided in the PSTN today. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of secure telephone identification mechanisms.

Steve


--047d7b16051509199604e35aebd4-- From jgunn6@csc.com Wed Aug 7 06:50:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B7621E8133; Wed, 7 Aug 2013 06:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WosOmp2+gc+J; Wed, 7 Aug 2013 06:50:42 -0700 (PDT) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by ietfa.amsl.com (Postfix) with ESMTP id 119E321E8131; Wed, 7 Aug 2013 06:50:42 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-87.messagelabs.com!1375883438!15582145!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25095 invoked from network); 7 Aug 2013 13:50:39 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-10.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Aug 2013 13:50:39 -0000 Received: from amer-gw09.amer.csc.com (cscmail.csc.com [20.6.39.245]) by amer-mta101.csc.com (8.13.8/8.13.8) with ESMTP id r77DkkYb004398; Wed, 7 Aug 2013 09:46:46 -0400 In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC24B41@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <00C069FD01E0324C9FFCADF539701DB3BBC24B41@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer MIME-Version: 1.0 X-KeepSent: AA599CCE:F13022FC-85257BC0:004C01C2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 7 Aug 2013 09:50:36 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 08/07/2013 09:44:05 AM, Serialize complete at 08/07/2013 09:44:05 AM Content-Type: multipart/alternative; boundary="=_alternative 004C0B8485257BC0_=" Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , "stir-bounces@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:50:47 -0000 This is a multipart message in MIME format. --=_alternative 004C0B8485257BC0_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSB0aGluayBmYWtlIG51bWJlcnMgd291bGQgd29yay4NCg0KSmFuZXQNCg0KVGhpcyBpcyBhIFBS SVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIA0KZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1h aWwgb2YgdGhlIG1pc3Rha2UgaW4gDQpkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250 ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byANCmJpbmQgQ1NDIHRvIGFueSBv cmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgDQp3cml0 dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRp bmcgdGhlIHVzZSBvZiANCmUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLg0KDQoNCg0KRnJvbTogICBN aWNoYWVsIEhhbW1lciA8bWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbT4NClRvOiAgICAgSmFu ZXQgUCBHdW5uL1VTQS9DU0NAQ1NDLCAiZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20iIA0KPGVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tPg0KQ2M6ICAgICAic3RpckBpZXRmLm9yZyIgPHN0aXJA aWV0Zi5vcmc+LCAiZGNyb2NrZXJAYmJpdy5uZXQiIA0KPGRjcm9ja2VyQGJiaXcubmV0PiwgInN0 aXItYm91bmNlc0BpZXRmLm9yZyIgPHN0aXItYm91bmNlc0BpZXRmLm9yZz4NCkRhdGU6ICAgMDgv MDYvMjAxMyAwNTozNCBQTQ0KU3ViamVjdDogICAgICAgIFJFOiBbc3Rpcl0gRWFybHkgSG9tZXdv cmsgICh3YXMgUmU6ICBNb3ZpbmcgZnJvbSBCT0YgdG8gDQpDaGFydGVyKQ0KDQoNCg0KSmFuZXQs DQogDQpDb3VsZG7igJl0IHlvdSB1c2UgZmFrZSBudW1iZXJzIHRoYXQgY291bGQgc3RpbGwgYmUg c2lnbmVkIGFuZCBwYXNzIA0KdmFsaWRhdGlvbj8NCiANCkkgdGhpbmsgeW91IGFyZSBzYXlpbmcg dGhhdCB0aGUgbnVtYmVycyB1c2VkIHdvdWxkIG5vdCB0cmFjZSBiYWNrIHRvIGEgDQpnaXZlbiBv cmdhbml6YXRpb24sIG9yIHdvdWxkIHRyYWNlIHRvIHN0b3JlZnJvbnQuY29tDQogDQpNaWtlDQog DQogDQpGcm9tOiBzdGlyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGlyLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiANCkphbmV0IFAgR3Vubg0KU2VudDogVHVlc2RheSwgQXVndXN0 IDA2LCAyMDEzIDU6MjQgUE0NClRvOiBFcmljIEJ1cmdlcg0KQ2M6IHN0aXJAaWV0Zi5vcmc7IGRj cm9ja2VyQGJiaXcubmV0OyBzdGlyLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rp cl0gRWFybHkgSG9tZXdvcmsgKHdhcyBSZTogTW92aW5nIGZyb20gQk9GIHRvIENoYXJ0ZXIpDQog DQpCdXQgdGhlcmUgbWF5IGJlIHNvbWUgbmF0aW9uYWwgc2VjdXJpdHkgc3lzdGVtcyB0aGF0IHJ1 biBvbiB0aGUgInB1YmxpYyIgDQpuZXR3b3JrIGFuZCBsZWdpdGltYXRlbHkgbmVlZCB0byBjb25j ZWFsIHRoZSByZWFsICJvcmlnaW5hdGluZyBudW1iZXIiIA0KZnJvbSBCT1RIIHRoZSBjYWxsZWQg cGFydHkgYW5kIHRoZSBpbnRlcm5hbCBjYWxsIHJlY29yZHMuIA0KDQpKYW5ldA0KDQoNCnN0aXIt Ym91bmNlc0BpZXRmLm9yZyB3cm90ZSBvbiAwOC8wNS8yMDEzIDA0OjM2OjQwIFBNOg0KDQo+IEZy b206IEVyaWMgQnVyZ2VyIDxlYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbT4gDQoNCj4gDQo+IEkg YWdyZWUgd2UgYXJlIG5vdCBsb29raW5nIGF0IGEgbmF0aW9uYWwgc2VjdXJpdHkgcHJpdmF0ZSBu ZXR3b3JrIA0KPiBhbmFseXNpcy4gSG93ZXZlciwgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIHBv dGVudGlhbCBlbmQgb2YgYW55IA0KPiBwcml2YWN5IG9yIGFub255bWl0eSBmb3IgQU5ZIEludGVy bmV0IGFwcGxpY2F0aW9uLCBtb3JlIGVzcGVjaWFsbHkgDQo+IEludGVybmV0IG11bHRpbWVkaWEg YXBwbGljYXRpb24uIFRoYXQgbmVlZHMgdG8gaGF2ZSBhIGxldmVsIG9mIA0KPiBhbmFseXNpcyB0 aGF0IGdvZXMgYmV5b25kIGVpdGhlciAiaG9wZWxlc3NseSBicm9rZW4iIG9yICJkb24ndCANCndv cnJ5YWJvdXQgaXQuIg0KPiANCg0K --=_alternative 004C0B8485257BC0_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgZmFrZSBudW1iZXJzIHdvdWxk IHdvcmsuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5K YW5ldDxicj4NCjxicj4NClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZQ0KZGVsZXRlIHdpdGhvdXQgY29weWluZyBh bmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4NCmRlbGl2ZXJ5 LiBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVy YXRlIHRvDQpiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1 cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4NCmFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRp YXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwNCmZvciBzdWNoIHB1 cnBvc2UuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0j NWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPk1pY2hhZWwgSGFtbWVyICZs dDttaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5UbzogJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+SmFuZXQgUCBH dW5uL1VTQS9DU0NAQ1NDLA0KJnF1b3Q7ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20mcXVvdDsg Jmx0O2VidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5DYzogJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7c3Rp ckBpZXRmLm9yZyZxdW90Ow0KJmx0O3N0aXJAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkY3JvY2tlckBi Yml3Lm5ldCZxdW90OyAmbHQ7ZGNyb2NrZXJAYmJpdy5uZXQmZ3Q7LA0KJnF1b3Q7c3Rpci1ib3Vu Y2VzQGlldGYub3JnJnF1b3Q7ICZsdDtzdGlyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRhdGU6ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjA4LzA2LzIwMTMgMDU6MzQgUE08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9y PSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDogJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtzdGlyXSBF YXJseQ0KSG9tZXdvcmsgJm5ic3A7KHdhcyBSZTogJm5ic3A7TW92aW5nIGZyb20gQk9GIHRvIENo YXJ0ZXIpPC9mb250Pg0KPGJyPg0KPGhyIG5vc2hhZGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+SmFuZXQsPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5Db3VsZG7igJl0IHlv dSB1c2UgZmFrZSBudW1iZXJzDQp0aGF0IGNvdWxkIHN0aWxsIGJlIHNpZ25lZCBhbmQgcGFzcyB2 YWxpZGF0aW9uPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJD YWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFj ZT0iQ2FsaWJyaSI+SSB0aGluayB5b3UgYXJlIHNheWluZyB0aGF0DQp0aGUgbnVtYmVycyB1c2Vk IHdvdWxkIG5vdCB0cmFjZSBiYWNrIHRvIGEgZ2l2ZW4gb3JnYW5pemF0aW9uLCBvciB3b3VsZA0K dHJhY2UgdG8gc3RvcmVmcm9udC5jb208L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMw MDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPk1pa2U8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gc3Rpci1ib3VuY2VzQGlldGYub3JnIFs8 L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0y IGZhY2U9IlRhaG9tYSI+bWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZzwvZm9udD48L2E+PGZv bnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYW5ldCBQIEd1 bm48Yj48YnI+DQpTZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDA2LCAyMDEzIDU6MjQgUE08Yj48 YnI+DQpUbzo8L2I+IEVyaWMgQnVyZ2VyPGI+PGJyPg0KQ2M6PC9iPiBzdGlyQGlldGYub3JnOyBk Y3JvY2tlckBiYml3Lm5ldDsgc3Rpci1ib3VuY2VzQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8 L2I+IFJlOiBbc3Rpcl0gRWFybHkgSG9tZXdvcmsgKHdhcyBSZTogTW92aW5nIGZyb20gQk9GIHRv IENoYXJ0ZXIpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkJ1dCB0aGVyZSBt YXkgYmUgc29tZSBuYXRpb25hbCBzZWN1cml0eSBzeXN0ZW1zDQp0aGF0IHJ1biBvbiB0aGUgJnF1 b3Q7cHVibGljJnF1b3Q7IG5ldHdvcmsgYW5kIGxlZ2l0aW1hdGVseSBuZWVkIHRvIGNvbmNlYWwN CnRoZSByZWFsICZxdW90O29yaWdpbmF0aW5nIG51bWJlciZxdW90OyBmcm9tIEJPVEggdGhlIGNh bGxlZCBwYXJ0eSBhbmQNCnRoZSBpbnRlcm5hbCBjYWxsIHJlY29yZHMuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48YnI+DQpKYW5ldDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i Q291cmllciBOZXciPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnN0aXItYm91 bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXci Pjx1PnN0aXItYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+DQp3cm90ZSBvbiAwOC8wNS8yMDEzIDA0OjM2OjQwIFBNOjxicj4NCjxi cj4NCiZndDsgRnJvbTogRXJpYyBCdXJnZXIgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3Vy aWVyIE5ldyI+PHU+ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb208L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhZ3JlZSB3ZSBhcmUgbm90IGxvb2tpbmcg YXQgYSBuYXRpb25hbCBzZWN1cml0eSBwcml2YXRlIG5ldHdvcmsNCjxicj4NCiZndDsgYW5hbHlz aXMuIEhvd2V2ZXIsIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBwb3RlbnRpYWwgZW5kIG9mIGFu eSA8YnI+DQomZ3Q7IHByaXZhY3kgb3IgYW5vbnltaXR5IGZvciBBTlkgSW50ZXJuZXQgYXBwbGlj YXRpb24sIG1vcmUgZXNwZWNpYWxseQ0KPGJyPg0KJmd0OyBJbnRlcm5ldCBtdWx0aW1lZGlhIGFw cGxpY2F0aW9uLiBUaGF0IG5lZWRzIHRvIGhhdmUgYSBsZXZlbCBvZiA8YnI+DQomZ3Q7IGFuYWx5 c2lzIHRoYXQgZ29lcyBiZXlvbmQgZWl0aGVyICZxdW90O2hvcGVsZXNzbHkgYnJva2VuJnF1b3Q7 IG9yDQomcXVvdDtkb24ndCB3b3JyeWFib3V0IGl0LiZxdW90Ozxicj4NCiZndDsgPC9mb250Pg0K PGJyPg0K --=_alternative 004C0B8485257BC0_=-- From pkyzivat@alum.mit.edu Wed Aug 7 06:52:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD6021E812C for ; Wed, 7 Aug 2013 06:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7f5z98nMVCp for ; Wed, 7 Aug 2013 06:52:15 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 3899821E8131 for ; Wed, 7 Aug 2013 06:52:15 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id 9nej1m00127AodY5ApsEMX; Wed, 07 Aug 2013 13:52:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 9psE1m00R3ZTu2S3fpsEfq; Wed, 07 Aug 2013 13:52:14 +0000 Message-ID: <5202510D.3010300@alum.mit.edu> Date: Wed, 07 Aug 2013 15:52:13 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> <01e501ce92f2$2b0398c0$810aca40$@shockey.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375883534; bh=mDSGnu3WFidVTLTnDdm4l07LTIPoBE/lmhpi0hhPZvM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PaFjinJBtbFUfsHS6ZY2GrCmVcwFdjpvqsOS/ZtuC+KUo76dRjwwOyuGPY6KUk7p7 EDi8HbUAUzWeeQ2C0SnVYFpOHoPPtFaRF9iwYPaxIJiFJHPZ6vFWnLEUeovCyVNkTa josl6lhbyqGPpBzgw+RDVopq6bboCfhVUTI/W8a3RpH5abilXEpAmHAnSedYHxxHLK I5BEA5Br6arKr5VjYVy0pqPJWycMnBLeIoiGYSjuViQ6rmc+HfZQg0fzbVq2TNzZqU QP5nXJBJX9dYZiQ+zom3n2RbFjTKXSHerFnzezX+uP6yN1NbegwOPXo2X2hOCmSNux wbyP0GUd6wSvw== Subject: Re: [stir] Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:52:20 -0000 The problem with hiding identity from CDRs is billing. Carriers seem to want to charge for communication services. The information used for charging could be distinct from that used for proving caller identity to the called party, but there is likely to be quite good correlation between the two. I don't know how one can guarantee privacy in an environment that charges for service without trusting the intermediaries to hide the charging identity. Perhaps something could be worked out via an anonymous payment mechanism such as bitcoins. This isn't really an issue for STIR. There may be a need for another initiative to enable anonymous calling to any phone number. But I expect that many governments, including the US, might oppose that. Thanks, Paul On 8/7/13 1:00 AM, Hadriel Kaplan wrote: > > Actually, I always forget which call direction this needs to happen in - or maybe it needs to happen in both directions. But this is just an example anyway, of one reason a government might want to hide the real calling party number from CDRs. I'm not saying it's the primary use-case, or that it even happens in practice in the real world. It's just an example people use in public forums such as this, as to why one needs to be able to hide such things. > > The issue isn't about the NSA necessarily - the issue is employees at the carriers along the path. CDRs are viewable by too many employees, in too many carriers along the call path. > > Safe houses (places to hide informants/witnesses) are meant to stay safe and anonymous, obviously - in particular from large criminal organizations with plenty of money, people, and muscle power. In the FBI's case, for example, they need to protect safe houses even from other government organizations they might be investigating/prosecuting. They have to distrust each other, for good reason. Since you're in DC, you know this better than me. :) > > So if you're an FBI office/agent/SAC or whatever, and you need to talk to the safe house regularly, you don't want to leave a trace in CDRs of your calling party number... because then someone who knows who the office/SAC is for a case, and their phone number, can get a hold of CDRs and look for who that office/SAC is calling, and then figure out the number to the safe house. Or vice versa, if the Safe House calls the SAC, the CDRs show calls to the SAC from a safe-house number. (again, I can't remember which call direction was the one used in the example I'd heard, or if it's both ways) Once you have potential Safe-House phone numbers, it's not hard to track down location, since the whole premise here is you have the money/power to co-opt employees at carriers. > > Again, I have no idea if this is what really drives the need - it's just an example I've been told in other public fora. > > We do similar things for Lawful Intercept, for which the requirements and mechanisms are publicly known/documented for several countries - not all countries have the same rules or mechanisms, but they're generally similar. No CDR entries are recorded/generated about who's under warrant, being wiretapped past/present/future, etc. If you looked at a CDR for a wiretapped call, nothing would appear different from a regular call. > > -hadriel > > > On Aug 6, 2013, at 6:13 PM, Richard Shockey wrote: > >> >> OK .. so the FBI or CIA doesn't want the NSA to know who they are calling? >> >> Sorry its cocktail hour on the US east coast. >> >> I shudder thinking about the corner cases here need to be listed in detail. >> .... >> >> -----Original Message----- >> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] >> Sent: Tuesday, August 06, 2013 6:03 PM >> To: Richard Shockey >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) >> >> >> Example: an FBI office or agent calls a safe house. >> >> -hadriel >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From br@brianrosen.net Wed Aug 7 07:09:12 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7D21F9C26 for ; Wed, 7 Aug 2013 07:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.72 X-Spam-Level: X-Spam-Status: No, score=-102.72 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txzs2v5xYxqp for ; Wed, 7 Aug 2013 07:09:07 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id BDFA421F9D12 for ; Wed, 7 Aug 2013 07:09:07 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so1939357pbc.22 for ; Wed, 07 Aug 2013 07:09:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ObRqy3gGcANa9MX4VjAHrmCPzhCkOPwB8VjEqiN0ofs=; b=BbOIeyFABusihSpdvgW9Fc6A1qav6TT+KzqryW2999ayfIMAikzLYpkpqplCMND61Q m61hhSuQzEbvhBsyJWtbhue26aEKE4GfB/Y7pZG7g4MLN8L6lxNQ6dTCZ6lunNJgKkqS 7AUDimqQkxMtUD+ot3m0GX3PSogIxxR0a+inHBKNBIUc8SwG7OFE3uaUnrsik1Q0osyJ JCEVD/nWL4AXGKThqBch2tyCnsOGlHoHvhmNG6lpjkLUa+U/LdWb9dHl00Kgxyd6iQVZ S/FQXF/MfyRIfDh8x4tllBu4TIpN+8Xp8AB2Et+onnkN8VffJL9gYWwoAp7cc/2wld2z EhEw== X-Gm-Message-State: ALoCoQk1xArr2epi7e3zrhN2GR2Syimx287D5vhTYl8wR5cc8Bb/zo4fYXKcXntrL4L2BKSA/UHh MIME-Version: 1.0 X-Received: by 10.66.26.112 with SMTP id k16mr867420pag.65.1375884547466; Wed, 07 Aug 2013 07:09:07 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Wed, 7 Aug 2013 07:09:07 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <00C069FD01E0324C9FFCADF539701DB3BBC24B41@EX2K10MB1.corp.yaanatech.com> Date: Wed, 7 Aug 2013 10:09:07 -0400 Message-ID: From: Brian Rosen To: Janet P Gunn Content-Type: multipart/alternative; boundary=bcaec52998b5b43b8904e35c1582 Cc: "stir@ietf.org" , Michael Hammer , "dcrocker@bbiw.net" , "stir-bounces@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:09:12 -0000 --bcaec52998b5b43b8904e35c1582 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Do we need any charter language changes? In the STIR scheme, there are no "fake" numbers, but of course there are way to get numbers allocated for such uses and obtain the credentials associated with those numbers so they can be used to send calls. Brian On Wednesday, August 7, 2013, Janet P Gunn wrote: > I think fake numbers would work. > > Janet > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind CSC to any order or other contract unless pursuant to explicit writt= en > agreement or government initiative expressly permitting the use of e-mail > for such purpose. > > > > From: Michael Hammer > > > To: Janet P Gunn/USA/CSC@CSC, "eburger@standardstrack.com" > 'eburger@standardstrack.com');>> > Cc: "stir@ietf.org " = < > stir@ietf.org >, " > dcrocker@bbiw.net " < > dcrocker@bbiw.net >, " > stir-bounces@ietf.org 'stir-bounces@ietf.org');>" 'cvml', 'stir-bounces@ietf.org');>> > Date: 08/06/2013 05:34 PM > Subject: RE: [stir] Early Homework (was Re: Moving from BOF to > Charter) > ------------------------------ > > > > Janet, > > Couldn=92t you use fake numbers that could still be signed and pass > validation? > > I think you are saying that the numbers used would not trace back to a > given organization, or would trace to storefront.com > > Mike > > > *From:* stir-bounces@ietf.org 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org] > *On Behalf Of *Janet P Gunn* > Sent:* Tuesday, August 06, 2013 5:24 PM* > To:* Eric Burger* > Cc:* stir@ietf.org ; > dcrocker@bbiw.net ; > stir-bounces@ietf.org 'stir-bounces@ietf.org');>* > Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > But there may be some national security systems that run on the "public" > network and legitimately need to conceal the real "originating number" fr= om > BOTH the called party and the internal call records. > > Janet > > * > **stir-bounces@ietf.org* 'stir-bounces@ietf.org');> wrote on 08/05/2013 04:36:40 PM: > > > From: Eric Burger <*eburger@standardstrack.com* 'cvml', 'eburger@standardstrack.com');>> > > > > > I agree we are not looking at a national security private network > > analysis. However, we are talking about the potential end of any > > privacy or anonymity for ANY Internet application, more especially > > Internet multimedia application. That needs to have a level of > > analysis that goes beyond either "hopelessly broken" or "don't > worryabout it." > > > --bcaec52998b5b43b8904e35c1582 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Do we need any charter language changes?

In the STIR sch= eme, there are no "fake" numbers, but of course there are way to = get numbers allocated for such uses and obtain the credentials associated w= ith those numbers so they can be used to send calls.

Brian


On Wednesday, Augu= st 7, 2013, Janet P Gunn wrote:
I think fake numbers would work.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From: =A0 =A0 = =A0 =A0Michael Hammer <michael.hammer@yaanatech.com>
To: =A0 =A0 =A0 =A0Janet P Gunn/USA/CSC@CSC, "eburger@standardstrack.com" <= eburger@standardstrack.com>
Cc: =A0 =A0 =A0 =A0"stir@ie= tf.org" <stir@ietf.org>, "dcrocker= @bbiw.net" <dcrocker@bbiw.net>, "stir-bounces@ietf.org" <stir-bounces@ietf.org>
Date: =A0 =A0 = =A0 =A008/06/2013 05:34 PM
Subject: =A0 =A0 =A0 =A0RE: [stir] Early Homework =A0(was Re: =A0Moving from BOF to Charter)



Janet,
=A0
Couldn=92t you use fake number= s that could still be signed and pass validation?
=A0
I think you are saying that the numbers used would not trace back to a given organization, or would trace to storefront.com=
=A0
Mike
=A0
=A0
From: stir-bounces@= ietf.org [mailto:st= ir-bounces@ietf.org] On Behalf Of Janet P Gunn
Sent: Tuesday, August 06, 2013 5:24 PM
To: Eric Burger
Cc: stir@ietf.org; dcrocker@bbiw.= net; stir-bounces@ietf.org
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)=
=A0
But there may be some national security systems that run on the "public" network and legitimately need to conceal the real "originating number" from BOTH the called party and the internal call records.=

Janet


stir-bounces@ietf.org wrote on 08/05/2013 04:36:40 PM:

> From: Eric Burger <eburger@standardstrack.com= >

>
> I agree we are not looking at a national security private network
> analysis. However, we are talking about the potential end of any
> privacy or anonymity for ANY Internet application, more especially
> Internet multimedia application. That needs to have a level of
> analysis that goes beyond either "hopelessly broken" or "don't worryabout it."
>
--bcaec52998b5b43b8904e35c1582-- From jgunn6@csc.com Wed Aug 7 07:09:22 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1FC11E8124; Wed, 7 Aug 2013 07:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4o1Gxv2cl-U; Wed, 7 Aug 2013 07:09:16 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4637921E811F; Wed, 7 Aug 2013 07:09:16 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-86.messagelabs.com!1375884553!41063707!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25487 invoked from network); 7 Aug 2013 14:09:14 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-9.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Aug 2013 14:09:14 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (8.13.8/8.13.8) with ESMTP id r77E6JvO024732; Wed, 7 Aug 2013 10:06:19 -0400 In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> <01e501ce92f2$2b0398c0$810aca40$@shockey.us> To: Hadriel Kaplan MIME-Version: 1.0 X-KeepSent: 2293D50F:2A7B7D53-85257BC0:004CEAA8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 7 Aug 2013 10:09:11 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 08/07/2013 10:02:40 AM, Serialize complete at 08/07/2013 10:02:40 AM Content-Type: multipart/alternative; boundary="=_alternative 004DBF2485257BC0_=" Cc: stir@ietf.org, stir-bounces@ietf.org, Richard Shockey Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:09:22 -0000 This is a multipart message in MIME format. --=_alternative 004DBF2485257BC0_= Content-Type: text/plain; charset="US-ASCII" That is not the specific case I was thinking of, but it suffices as an example. You do not want carrier employees (who have legitimate reasons to look at CDRs, but do not typically have security clearances) to know where particular phone calls are coming from. "Fake numbers" should be sufficient. I think the reference in the charter to "equivalent to what it (sic) provided in the PSTN today " covers it. Janet stir-bounces@ietf.org wrote on 08/06/2013 07:00:18 PM: > From: Hadriel Kaplan > To: Richard Shockey > Cc: stir@ietf.org > Date: 08/06/2013 07:00 PM > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > Sent by: stir-bounces@ietf.org > > > Actually, I always forget which call direction this needs to happen > in - or maybe it needs to happen in both directions. But this is > just an example anyway, of one reason a government might want to > hide the real calling party number from CDRs. I'm not saying it's > the primary use-case, or that it even happens in practice in the > real world. It's just an example people use in public forums such > as this, as to why one needs to be able to hide such things. > > The issue isn't about the NSA necessarily - the issue is employees > at the carriers along the path. CDRs are viewable by too many > employees, in too many carriers along the call path. > > Safe houses (places to hide informants/witnesses) are meant to stay > safe and anonymous, obviously - in particular from large criminal > organizations with plenty of money, people, and muscle power. In > the FBI's case, for example, they need to protect safe houses even > from other government organizations they might be investigating/ > prosecuting. They have to distrust each other, for good reason. > Since you're in DC, you know this better than me. :) > > So if you're an FBI office/agent/SAC or whatever, and you need to > talk to the safe house regularly, you don't want to leave a trace in > CDRs of your calling party number... because then someone who knows > who the office/SAC is for a case, and their phone number, can get a > hold of CDRs and look for who that office/SAC is calling, and then > figure out the number to the safe house. Or vice versa, if the Safe > House calls the SAC, the CDRs show calls to the SAC from a safe- > house number. (again, I can't remember which call direction was the > one used in the example I'd heard, or if it's both ways) Once you > have potential Safe-House phone numbers, it's not hard to track down > location, since the whole premise here is you have the money/power > to co-opt employees at carriers. > > Again, I have no idea if this is what really drives the need - it's > just an example I've been told in other public fora. > > We do similar things for Lawful Intercept, for which the > requirements and mechanisms are publicly known/documented for > several countries - not all countries have the same rules or > mechanisms, but they're generally similar. No CDR entries are > recorded/generated about who's under warrant, being wiretapped past/ > present/future, etc. If you looked at a CDR for a wiretapped call, > nothing would appear different from a regular call. > > -hadriel > > > On Aug 6, 2013, at 6:13 PM, Richard Shockey wrote: > > > > > OK .. so the FBI or CIA doesn't want the NSA to know who they are calling? > > > > Sorry its cocktail hour on the US east coast. > > > > I shudder thinking about the corner cases here need to be listed in detail. > > .... > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > > Sent: Tuesday, August 06, 2013 6:03 PM > > To: Richard Shockey > > Cc: stir@ietf.org > > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > > > > > Example: an FBI office or agent calls a safe house. > > > > -hadriel > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --=_alternative 004DBF2485257BC0_= Content-Type: text/html; charset="US-ASCII"
That is not the specific case I was thinking of, but it suffices as an example.

You do not want carrier employees (who have legitimate reasons to look at CDRs, but do not typically have security clearances) to know where particular phone calls are coming from.

"Fake numbers" should be sufficient.

I think the reference in the charter to "equivalent to what it (sic) provided in the PSTN today " covers it.

Janet

stir-bounces@ietf.org wrote on 08/06/2013 07:00:18 PM:

> From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
> To: Richard Shockey <richard@shockey.us>
> Cc: stir@ietf.org
> Date: 08/06/2013 07:00 PM
> Subject: Re: [stir] Early Homework  (was Re:  Moving from BOF to Charter)
> Sent by: stir-bounces@ietf.org
>
>
> Actually, I always forget which call direction this needs to happen
> in - or maybe it needs to happen in both directions.  But this is
> just an example anyway, of one reason a government might want to
> hide the real calling party number from CDRs.  I'm not saying it's
> the primary use-case, or that it even happens in practice in the
> real world.  It's just an example people use in public forums such
> as this, as to why one needs to be able to hide such things.
>
> The issue isn't about the NSA necessarily - the issue is employees
> at the carriers along the path.  CDRs are viewable by too many
> employees, in too many carriers along the call path.
>
> Safe houses (places to hide informants/witnesses) are meant to stay
> safe and anonymous, obviously - in particular from large criminal
> organizations with plenty of money, people, and muscle power.  In
> the FBI's case, for example, they need to protect safe houses even
> from other government organizations they might be investigating/
> prosecuting.  They have to distrust each other, for good reason.  
> Since you're in DC, you know this better than me. :)
>
> So if you're an FBI office/agent/SAC or whatever, and you need to
> talk to the safe house regularly, you don't want to leave a trace in
> CDRs of your calling party number... because then someone who knows
> who the office/SAC is for a case, and their phone number, can get a
> hold of CDRs and look for who that office/SAC is calling, and then
> figure out the number to the safe house.  Or vice versa, if the Safe
> House calls the SAC, the CDRs show calls to the SAC from a safe-
> house number. (again, I can't remember which call direction was the
> one used in the example I'd heard, or if it's both ways)  Once you
> have potential Safe-House phone numbers, it's not hard to track down
> location, since the whole premise here is you have the money/power
> to co-opt employees at carriers.
>
> Again, I have no idea if this is what really drives the need - it's
> just an example I've been told in other public fora.
>
> We do similar things for Lawful Intercept, for which the
> requirements and mechanisms are publicly known/documented for
> several countries - not all countries have the same rules or
> mechanisms, but they're generally similar.  No CDR entries are
> recorded/generated about who's under warrant, being wiretapped past/
> present/future, etc.  If you looked at a CDR for a wiretapped call,
> nothing would appear different from a regular call.
>
> -hadriel
>
>
> On Aug 6, 2013, at 6:13 PM, Richard Shockey <richard@shockey.us> wrote:
>
> >
> > OK .. so the FBI or CIA doesn't want the NSA to know who they are calling?
> >
> > Sorry its cocktail hour on the US east coast.
> >
> > I shudder thinking about the corner cases here need to be listed in detail.
> > .... <sigh>
> >
> > -----Original Message-----
> > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]
> > Sent: Tuesday, August 06, 2013 6:03 PM
> > To: Richard Shockey
> > Cc: stir@ietf.org
> > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)
> >
> >
> > Example: an FBI office or agent calls a safe house.
> >
> > -hadriel
> >
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
 --=_alternative 004DBF2485257BC0_=-- From hadriel.kaplan@oracle.com Wed Aug 7 07:38:12 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD91211E8136 for ; Wed, 7 Aug 2013 07:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3obAZg4NBpKx for ; Wed, 7 Aug 2013 07:38:06 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2755D11E8134 for ; Wed, 7 Aug 2013 07:38:05 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r77Ec3SD014428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 14:38:04 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77Ec356016395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 14:38:03 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77Ec2pL016373; Wed, 7 Aug 2013 14:38:02 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Aug 2013 07:38:02 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5202510D.3010300@alum.mit.edu> Date: Wed, 7 Aug 2013 10:38:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5532D97B-0834-40A0-A8A9-FFBB8AEC2AA1@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> <01e501ce92f2$2b0398c0$810aca40$@shockey.us> <5202510D.3010300@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org Subject: Re: [stir] Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:38:12 -0000 It depends on how you mean that. For the governmental type calls we = were talking about, I believe it's handled a slightly different way = anyway, and I don't think it's worth speculating about here. But for general anonymous calls: there are calls made on the PSTN (and = its SIP equivalent), right now, that really don't have source caller = identity in CDRs. CDRs are still generated for them, but there is no = calling party info with the phone number of the calling phone. Afaik, = in TDM land it's the ANI number that is used for charging, not the CLID. = And that's a different field, often identifying a generic billing = number for a company/organization rather than a specific line/phone, and = it's not delivered/presented to end users when they receive the call. = In SIP land, providers use various headers to encode a billing identity, = separately from a source calling identity. Some use P-DCS-Billing-Info = for example; some even seen some use P-Asserted-Identity for it (sadly). = Dan York has had a draft out for several years, defining a new header = for it (draft-york-sipping-p-charge-info), and I've been told it gets = used by some folks already. Clearly it does require trusting the carriers to hide the billing = information from the called user, but (1) you have to trust them for a = heck of a lot more than that anyway, especially in terms of privacy = issues, and (2) that has not appeared to be a problem in the real world. = As you noted, it's not an issue for STIR. -hadriel On Aug 7, 2013, at 9:52 AM, Paul Kyzivat wrote: > The problem with hiding identity from CDRs is billing. > Carriers seem to want to charge for communication services. > The information used for charging could be distinct from that used for = proving caller identity to the called party, but there is likely to be = quite good correlation between the two. >=20 > I don't know how one can guarantee privacy in an environment that = charges for service without trusting the intermediaries to hide the = charging identity. >=20 > Perhaps something could be worked out via an anonymous payment = mechanism such as bitcoins. >=20 > This isn't really an issue for STIR. There may be a need for another = initiative to enable anonymous calling to any phone number. But I expect = that many governments, including the US, might oppose that. >=20 > Thanks, > Paul >=20 > On 8/7/13 1:00 AM, Hadriel Kaplan wrote: >>=20 >> Actually, I always forget which call direction this needs to happen = in - or maybe it needs to happen in both directions. But this is just = an example anyway, of one reason a government might want to hide the = real calling party number from CDRs. I'm not saying it's the primary = use-case, or that it even happens in practice in the real world. It's = just an example people use in public forums such as this, as to why one = needs to be able to hide such things. >>=20 >> The issue isn't about the NSA necessarily - the issue is employees at = the carriers along the path. CDRs are viewable by too many employees, = in too many carriers along the call path. >>=20 >> Safe houses (places to hide informants/witnesses) are meant to stay = safe and anonymous, obviously - in particular from large criminal = organizations with plenty of money, people, and muscle power. In the = FBI's case, for example, they need to protect safe houses even from = other government organizations they might be investigating/prosecuting. = They have to distrust each other, for good reason. Since you're in DC, = you know this better than me. :) >>=20 >> So if you're an FBI office/agent/SAC or whatever, and you need to = talk to the safe house regularly, you don't want to leave a trace in = CDRs of your calling party number... because then someone who knows who = the office/SAC is for a case, and their phone number, can get a hold of = CDRs and look for who that office/SAC is calling, and then figure out = the number to the safe house. Or vice versa, if the Safe House calls = the SAC, the CDRs show calls to the SAC from a safe-house number. = (again, I can't remember which call direction was the one used in the = example I'd heard, or if it's both ways) Once you have potential = Safe-House phone numbers, it's not hard to track down location, since = the whole premise here is you have the money/power to co-opt employees = at carriers. >>=20 >> Again, I have no idea if this is what really drives the need - it's = just an example I've been told in other public fora. >>=20 >> We do similar things for Lawful Intercept, for which the requirements = and mechanisms are publicly known/documented for several countries - not = all countries have the same rules or mechanisms, but they're generally = similar. No CDR entries are recorded/generated about who's under = warrant, being wiretapped past/present/future, etc. If you looked at a = CDR for a wiretapped call, nothing would appear different from a regular = call. >>=20 >> -hadriel >>=20 From michael.hammer@yaanatech.com Wed Aug 7 07:56:07 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C722421F9EF5 for ; Wed, 7 Aug 2013 07:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq1q7d-7UDQE for ; Wed, 7 Aug 2013 07:56:03 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3121F9EE5 for ; Wed, 7 Aug 2013 07:56:03 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 7 Aug 2013 07:56:03 -0700 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "stir@ietf.org" Thread-Topic: [stir] Privacy Thread-Index: AQHOk3VXHrhcqsYNIU62anELqK87kpmJ1SDA Date: Wed, 7 Aug 2013 14:56:01 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC250DB@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> <01e501ce92f2$2b0398c0$810aca40$@shockey.us> <5202510D.3010300@alum.mit.edu> In-Reply-To: <5202510D.3010300@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.237] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D2_01CE935C.B4542210" MIME-Version: 1.0 Subject: Re: [stir] Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:56:08 -0000 ------=_NextPart_000_00D2_01CE935C.B4542210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I suspect that carriers will capture the signaling data, whether the numbers therein are valid or not. But, I think it out of scope for us to determine what they do with that. Leave that to ATIS, ETSI, and ITU-T. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, August 07, 2013 9:52 AM To: stir@ietf.org Subject: Re: [stir] Privacy The problem with hiding identity from CDRs is billing. Carriers seem to want to charge for communication services. The information used for charging could be distinct from that used for proving caller identity to the called party, but there is likely to be quite good correlation between the two. I don't know how one can guarantee privacy in an environment that charges for service without trusting the intermediaries to hide the charging identity. Perhaps something could be worked out via an anonymous payment mechanism such as bitcoins. This isn't really an issue for STIR. There may be a need for another initiative to enable anonymous calling to any phone number. But I expect that many governments, including the US, might oppose that. Thanks, Paul On 8/7/13 1:00 AM, Hadriel Kaplan wrote: > > Actually, I always forget which call direction this needs to happen in - or maybe it needs to happen in both directions. But this is just an example anyway, of one reason a government might want to hide the real calling party number from CDRs. I'm not saying it's the primary use-case, or that it even happens in practice in the real world. It's just an example people use in public forums such as this, as to why one needs to be able to hide such things. > > The issue isn't about the NSA necessarily - the issue is employees at the carriers along the path. CDRs are viewable by too many employees, in too many carriers along the call path. > > Safe houses (places to hide informants/witnesses) are meant to stay > safe and anonymous, obviously - in particular from large criminal > organizations with plenty of money, people, and muscle power. In the > FBI's case, for example, they need to protect safe houses even from > other government organizations they might be > investigating/prosecuting. They have to distrust each other, for good > reason. Since you're in DC, you know this better than me. :) > > So if you're an FBI office/agent/SAC or whatever, and you need to talk to the safe house regularly, you don't want to leave a trace in CDRs of your calling party number... because then someone who knows who the office/SAC is for a case, and their phone number, can get a hold of CDRs and look for who that office/SAC is calling, and then figure out the number to the safe house. Or vice versa, if the Safe House calls the SAC, the CDRs show calls to the SAC from a safe-house number. (again, I can't remember which call direction was the one used in the example I'd heard, or if it's both ways) Once you have potential Safe-House phone numbers, it's not hard to track down location, since the whole premise here is you have the money/power to co-opt employees at carriers. > > Again, I have no idea if this is what really drives the need - it's just an example I've been told in other public fora. > > We do similar things for Lawful Intercept, for which the requirements and mechanisms are publicly known/documented for several countries - not all countries have the same rules or mechanisms, but they're generally similar. No CDR entries are recorded/generated about who's under warrant, being wiretapped past/present/future, etc. If you looked at a CDR for a wiretapped call, nothing would appear different from a regular call. > > -hadriel > > > On Aug 6, 2013, at 6:13 PM, Richard Shockey wrote: > >> >> OK .. so the FBI or CIA doesn't want the NSA to know who they are calling? >> >> Sorry its cocktail hour on the US east coast. >> >> I shudder thinking about the corner cases here need to be listed in detail. >> .... >> >> -----Original Message----- >> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] >> Sent: Tuesday, August 06, 2013 6:03 PM >> To: Richard Shockey >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> >> Example: an FBI office or agent calls a safe house. >> >> -hadriel >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00D2_01CE935C.B4542210 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgw NzE0NTYwMVowIwYJKoZIhvcNAQkEMRYEFH6jlxPS46VmpC2V9NdUv8UDUAr9MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEALEY/kmxthgNfZmhMbAqTBMuYy6RYzYQLEnmBEe/X Gk3XZ5L7nlzloYww3W/TcTKkOAhzt1sVjcsjWAyUhR7idQvYgJPIY9eeNHbyj1l8ZUAoJHujvQge +b9AcCn9B76VyhJ/V8RjYJzvXhlIxAsfGEwyTmCbWVbZdZHY/Dq+AisTDVrlxFX1mMd8nEqCBmD9 3xBClYJoEOY6jKOTB4Au23lpOBrordRnec6rL+rRa08+puTL9vEW+f9QxkqbQfE2ZU1YqCyUOLFL tE7TkXQ3hBUC95cOs8ikTovqz9mOakMKSj2+08pxJLXIhT+HDhIGiHL/YrevyOyd4MfiCytfxQAA AAAAAA== ------=_NextPart_000_00D2_01CE935C.B4542210-- From timothy.dwight@verizon.com Wed Aug 7 08:13:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E3821F8956; Wed, 7 Aug 2013 08:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvRW-ZRC4P6C; Wed, 7 Aug 2013 08:13:15 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id CA55F21F85F4; Wed, 7 Aug 2013 08:13:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 07 Aug 2013 15:13:08 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,833,1367971200"; d="scan'208,217";a="532219964" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 07 Aug 2013 15:13:07 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Wed, 7 Aug 2013 11:13:07 -0400 To: Janet P Gunn , Hadriel Kaplan Date: Wed, 7 Aug 2013 11:13:06 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: Ac6Td8NAnIN/+CA3QemtjAvmzDfn/wACHOVA Message-ID: <2B0F677F0B95454297753F58D4A07FA301298E31D8@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> <01e501ce92f2$2b0398c0$810aca40$@shockey.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2B0F677F0B95454297753F58D4A07FA301298E31D8FHDP1LUMXC7V3_" MIME-Version: 1.0 Cc: "stir@ietf.org" , "stir-bounces@ietf.org" , Richard Shockey Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:13:21 -0000 --_000_2B0F677F0B95454297753F58D4A07FA301298E31D8FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Janet, Ideally the number sent would allow us to identify the billable party even = if it doesn't identify the location from which the call was sent or the ind= ividual that sent it. Is that consistent with your "fake number" idea? tim From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Jan= et P Gunn Sent: Wednesday, August 07, 2013 7:09 AM To: Hadriel Kaplan Cc: stir@ietf.org; stir-bounces@ietf.org; Richard Shockey Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) That is not the specific case I was thinking of, but it suffices as an exam= ple. You do not want carrier employees (who have legitimate reasons to look at C= DRs, but do not typically have security clearances) to know where particula= r phone calls are coming from. "Fake numbers" should be sufficient. I think the reference in the charter to "equivalent to what it (sic) provid= ed in the PSTN today " covers it. Janet stir-bounces@ietf.org wrote on 08/06/2013 07:= 00:18 PM: > From: Hadriel Kaplan > > To: Richard Shockey > > Cc: stir@ietf.org > Date: 08/06/2013 07:00 PM > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > Sent by: stir-bounces@ietf.org > > > Actually, I always forget which call direction this needs to happen > in - or maybe it needs to happen in both directions. But this is > just an example anyway, of one reason a government might want to > hide the real calling party number from CDRs. I'm not saying it's > the primary use-case, or that it even happens in practice in the > real world. It's just an example people use in public forums such > as this, as to why one needs to be able to hide such things. > > The issue isn't about the NSA necessarily - the issue is employees > at the carriers along the path. CDRs are viewable by too many > employees, in too many carriers along the call path. > > Safe houses (places to hide informants/witnesses) are meant to stay > safe and anonymous, obviously - in particular from large criminal > organizations with plenty of money, people, and muscle power. In > the FBI's case, for example, they need to protect safe houses even > from other government organizations they might be investigating/ > prosecuting. They have to distrust each other, for good reason. > Since you're in DC, you know this better than me. :) > > So if you're an FBI office/agent/SAC or whatever, and you need to > talk to the safe house regularly, you don't want to leave a trace in > CDRs of your calling party number... because then someone who knows > who the office/SAC is for a case, and their phone number, can get a > hold of CDRs and look for who that office/SAC is calling, and then > figure out the number to the safe house. Or vice versa, if the Safe > House calls the SAC, the CDRs show calls to the SAC from a safe- > house number. (again, I can't remember which call direction was the > one used in the example I'd heard, or if it's both ways) Once you > have potential Safe-House phone numbers, it's not hard to track down > location, since the whole premise here is you have the money/power > to co-opt employees at carriers. > > Again, I have no idea if this is what really drives the need - it's > just an example I've been told in other public fora. > > We do similar things for Lawful Intercept, for which the > requirements and mechanisms are publicly known/documented for > several countries - not all countries have the same rules or > mechanisms, but they're generally similar. No CDR entries are > recorded/generated about who's under warrant, being wiretapped past/ > present/future, etc. If you looked at a CDR for a wiretapped call, > nothing would appear different from a regular call. > > -hadriel > > > On Aug 6, 2013, at 6:13 PM, Richard Shockey > wrote: > > > > > OK .. so the FBI or CIA doesn't want the NSA to know who they are calli= ng? > > > > Sorry its cocktail hour on the US east coast. > > > > I shudder thinking about the corner cases here need to be listed in det= ail. > > .... > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > > Sent: Tuesday, August 06, 2013 6:03 PM > > To: Richard Shockey > > Cc: stir@ietf.org > > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > > > > > Example: an FBI office or agent calls a safe house. > > > > -hadriel > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --_000_2B0F677F0B95454297753F58D4A07FA301298E31D8FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Janet,

 

Ideally the number se= nt would allow us to identify the billable party even if it doesn’t i= dentify the location from which the call was sent or the individual that se= nt it.  Is that consistent with your “fake number” idea?

 

tim

 

= From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Janet P Gunn
Sent: Wednesday, August 07, 2013 7:09 AM
<= b>To: Hadriel Kaplan
Cc: stir@ietf.org; stir-bounces@ietf.org= ; Richard Shockey
Subject: Re: [stir] Early Homework (was Re: Mov= ing from BOF to Charter)

&nb= sp;


That is not the specific case I was thinking o= f, but it suffices as an example.

You do not want carrier employees (= who have legitimate reasons to look at CDRs, but do not typically have secu= rity clearances) to know where particular phone calls are coming from.

"Fake numbers" should be sufficient.

I think the referenc= e in the charter to "equivalent to what it (sic) provided in th= e PSTN today " covers it.

Janet

stir-bounces@iet= f.org wrote on 08/06/2013 07:00:18 PM:

> From: Hadriel Kaplan= <hadriel.kaplan@oracle.com= >
> To: Rich= ard Shockey <richard@shockey.us>
> Cc: stir@ietf.org
> Date: 08/06/2013 07:00 PM
> Subject: Re: [stir] Early Homework &nbs= p;(was Re:  Moving from BOF to Charter)
> Sent by: stir-bounces@ietf.org
>
>
> Actually, I always forget which call= direction this needs to happen
> in - or maybe it needs to= happen in both directions.  But this is
> just an exa= mple anyway, of one reason a government might want to
> hid= e the real calling party number from CDRs.  I'm not saying it's <= br>> the primary use-case, or that it even happens in practice in th= e
> real world.  It's just an example people use in pu= blic forums such
> as this, as to why one needs to be able = to hide such things.
>
> The issue isn't abo= ut the NSA necessarily - the issue is employees
> at the ca= rriers along the path.  CDRs are viewable by too many
>= ; employees, in too many carriers along the call path.
>
> Safe houses (places to hide informants/witnesses) are meant = to stay
> safe and anonymous, obviously - in particular fro= m large criminal
> organizations with plenty of money, peop= le, and muscle power.  In
> the FBI's case, for exampl= e, they need to protect safe houses even
> from other gover= nment organizations they might be investigating/
> prosecuti= ng.  They have to distrust each other, for good reason.  > Since you're in DC, you know this better than me. :)
= >
> So if you're an FBI office/agent/SAC or whatever, an= d you need to
> talk to the safe house regularly, you don't= want to leave a trace in
> CDRs of your calling party numbe= r... because then someone who knows
> who the office/SAC is= for a case, and their phone number, can get a
> hold of CD= Rs and look for who that office/SAC is calling, and then
> = figure out the number to the safe house.  Or vice versa, if the Safe
> House calls the SAC, the CDRs show calls to the SAC from a = safe-
> house number. (again, I can't remember which call di= rection was the
> one used in the example I'd heard, or if = it's both ways)  Once you
> have potential Safe-House = phone numbers, it's not hard to track down
> location, since= the whole premise here is you have the money/power
> to co= -opt employees at carriers.
>
> Again, I hav= e no idea if this is what really drives the need - it's
> j= ust an example I've been told in other public fora.
> <= br>> We do similar things for Lawful Intercept, for which the <= br>> requirements and mechanisms are publicly known/documented for <= /tt>
> several countries - not all countries have the same rules = or
> mechanisms, but they're generally similar.  No CD= R entries are
> recorded/generated about who's under warran= t, being wiretapped past/
> present/future, etc.  If yo= u looked at a CDR for a wiretapped call,
> nothing would ap= pear different from a regular call.
>
> -had= riel
>
>
> On Aug 6, 2013, a= t 6:13 PM, Richard Shockey <richar= d@shockey.us> wrote:
>
> > > > OK .. so the FBI or CIA doesn't want the NSA to know who th= ey are calling?
> >
> > Sorry its coc= ktail hour on the US east coast.
> >
> &g= t; I shudder thinking about the corner cases here need to be listed in deta= il.
> > .... <sigh>
> > > > -----Original Message-----
> > From: Hadri= el Kaplan [mailto:hadriel.kaplan@oracle.com<= /a>]
> > Sent: Tuesday, Augu= st 06, 2013 6:03 PM
> > To: Richard Shockey
&= gt; > Cc: stir@ietf.org
> > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to C= harter)
> >
> >
> >= Example: an FBI office or agent calls a safe house.
> > =
> > -hadriel
> >
>
> _______________________________________________
= > stir mailing list
> st= ir@ietf.org
> https://www.i= etf.org/mailman/listinfo/stir

= --_000_2B0F677F0B95454297753F58D4A07FA301298E31D8FHDP1LUMXC7V3_-- From jgunn6@csc.com Wed Aug 7 08:28:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D820411E813F; Wed, 7 Aug 2013 08:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+mJ+FJpHqCm; Wed, 7 Aug 2013 08:27:55 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7D221E8142; Wed, 7 Aug 2013 08:27:54 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-85.messagelabs.com!1375889272!41582648!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6342 invoked from network); 7 Aug 2013 15:27:52 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-7.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Aug 2013 15:27:52 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (8.13.8/8.13.8) with ESMTP id r77FNxXO026801; Wed, 7 Aug 2013 11:23:59 -0400 In-Reply-To: <2B0F677F0B95454297753F58D4A07FA301298E31D8@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> <01e501ce92f2$2b0398c0$810aca40$@shockey.us> <2B0F677F0B95454297753F58D4A07FA301298E31D8@FHDP1LUMXC7V31.us.one.verizon.com> To: "Dwight, Timothy M (Tim)" MIME-Version: 1.0 X-KeepSent: 96CAB0C8:7D4AEBC0-85257BC0:0054EBB6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 7 Aug 2013 11:27:50 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 08/07/2013 11:21:18 AM, Serialize complete at 08/07/2013 11:21:18 AM Content-Type: multipart/alternative; boundary="=_alternative 0054F21885257BC0_=" Cc: "stir@ietf.org" , Hadriel Kaplan , "stir-bounces@ietf.org" , Richard Shockey Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:28:12 -0000 This is a multipart message in MIME format. --=_alternative 0054F21885257BC0_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 ImVxdWl2YWxlbnQgdG8gd2hhdCBpdCAoc2ljKSBwcm92aWRlZCBpbiB0aGUgUFNUTiB0b2RheSAi IA0KDQoiRHdpZ2h0LCBUaW1vdGh5IE0gKFRpbSkiIDx0aW1vdGh5LmR3aWdodEB2ZXJpem9uLmNv bT4gd3JvdGUgb24gMDgvMDcvMjAxMyANCjExOjEzOjA2IEFNOg0KDQo+IEZyb206ICJEd2lnaHQs IFRpbW90aHkgTSAoVGltKSIgPHRpbW90aHkuZHdpZ2h0QHZlcml6b24uY29tPg0KPiBUbzogSmFu ZXQgUCBHdW5uL1VTQS9DU0NAQ1NDLCBIYWRyaWVsIEthcGxhbiA8aGFkcmllbC5rYXBsYW5Ab3Jh Y2xlLmNvbT4NCj4gQ2M6ICJzdGlyQGlldGYub3JnIiA8c3RpckBpZXRmLm9yZz4sICJzdGlyLWJv dW5jZXNAaWV0Zi5vcmciIDxzdGlyLQ0KPiBib3VuY2VzQGlldGYub3JnPiwgUmljaGFyZCBTaG9j a2V5IDxyaWNoYXJkQHNob2NrZXkudXM+DQo+IERhdGU6IDA4LzA3LzIwMTMgMTE6MTQgQU0NCj4g U3ViamVjdDogUkU6IFtzdGlyXSBFYXJseSBIb21ld29yayAgKHdhcyBSZTogIE1vdmluZyBmcm9t IEJPRiB0byANCkNoYXJ0ZXIpDQo+IA0KPiBKYW5ldCwNCj4gDQo+IElkZWFsbHkgdGhlIG51bWJl ciBzZW50IHdvdWxkIGFsbG93IHVzIHRvIGlkZW50aWZ5IHRoZSBiaWxsYWJsZSANCj4gcGFydHkg ZXZlbiBpZiBpdCBkb2VzbuKAmXQgaWRlbnRpZnkgdGhlIGxvY2F0aW9uIGZyb20gd2hpY2ggdGhl IGNhbGwgDQo+IHdhcyBzZW50IG9yIHRoZSBpbmRpdmlkdWFsIHRoYXQgc2VudCBpdC4gIElzIHRo YXQgY29uc2lzdGVudCB3aXRoIA0KPiB5b3VyIOKAnGZha2UgbnVtYmVy4oCdIGlkZWE/DQo+IA0K PiB0aW0NCj4gDQo+IEZyb206IHN0aXItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0aXItYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPiBKYW5ldCBQIEd1bm4NCj4gU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMDcsIDIwMTMgNzowOSBBTQ0KPiBUbzogSGFkcmllbCBLYXBsYW4NCj4g Q2M6IHN0aXJAaWV0Zi5vcmc7IHN0aXItYm91bmNlc0BpZXRmLm9yZzsgUmljaGFyZCBTaG9ja2V5 DQo+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gRWFybHkgSG9tZXdvcmsgKHdhcyBSZTogTW92aW5nIGZy b20gQk9GIHRvIENoYXJ0ZXIpDQo+IA0KPiANCj4gVGhhdCBpcyBub3QgdGhlIHNwZWNpZmljIGNh c2UgSSB3YXMgdGhpbmtpbmcgb2YsIGJ1dCBpdCBzdWZmaWNlcyBhcyANCj4gYW4gZXhhbXBsZS4g DQo+IA0KPiBZb3UgZG8gbm90IHdhbnQgY2FycmllciBlbXBsb3llZXMgKHdobyBoYXZlIGxlZ2l0 aW1hdGUgcmVhc29ucyB0byANCj4gbG9vayBhdCBDRFJzLCBidXQgZG8gbm90IHR5cGljYWxseSBo YXZlIHNlY3VyaXR5IGNsZWFyYW5jZXMpIHRvIGtub3cNCj4gd2hlcmUgcGFydGljdWxhciBwaG9u ZSBjYWxscyBhcmUgY29taW5nIGZyb20uIA0KPiANCj4gIkZha2UgbnVtYmVycyIgc2hvdWxkIGJl IHN1ZmZpY2llbnQuIA0KPiANCj4gSSB0aGluayB0aGUgcmVmZXJlbmNlIGluIHRoZSBjaGFydGVy IHRvICJlcXVpdmFsZW50IHRvIHdoYXQgaXQgKHNpYykNCj4gcHJvdmlkZWQgaW4gdGhlIFBTVE4g dG9kYXkgIiBjb3ZlcnMgaXQuIA0KPiANCj4gSmFuZXQgDQo+IA0KPiBzdGlyLWJvdW5jZXNAaWV0 Zi5vcmcgd3JvdGUgb24gMDgvMDYvMjAxMyAwNzowMDoxOCBQTToNCj4gDQo+ID4gRnJvbTogSGFk cmllbCBLYXBsYW4gPGhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20+IA0KPiA+IFRvOiBSaWNoYXJk IFNob2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz4gDQo+ID4gQ2M6IHN0aXJAaWV0Zi5vcmcgDQo+ ID4gRGF0ZTogMDgvMDYvMjAxMyAwNzowMCBQTSANCj4gPiBTdWJqZWN0OiBSZTogW3N0aXJdIEVh cmx5IEhvbWV3b3JrICAod2FzIFJlOiAgTW92aW5nIGZyb20gQk9GIHRvIA0KQ2hhcnRlcikgDQo+ ID4gU2VudCBieTogc3Rpci1ib3VuY2VzQGlldGYub3JnIA0KPiA+IA0KPiA+IA0KPiA+IEFjdHVh bGx5LCBJIGFsd2F5cyBmb3JnZXQgd2hpY2ggY2FsbCBkaXJlY3Rpb24gdGhpcyBuZWVkcyB0byBo YXBwZW4gDQo+ID4gaW4gLSBvciBtYXliZSBpdCBuZWVkcyB0byBoYXBwZW4gaW4gYm90aCBkaXJl Y3Rpb25zLiAgQnV0IHRoaXMgaXMgDQo+ID4ganVzdCBhbiBleGFtcGxlIGFueXdheSwgb2Ygb25l IHJlYXNvbiBhIGdvdmVybm1lbnQgbWlnaHQgd2FudCB0byANCj4gPiBoaWRlIHRoZSByZWFsIGNh bGxpbmcgcGFydHkgbnVtYmVyIGZyb20gQ0RScy4gIEknbSBub3Qgc2F5aW5nIGl0J3MgDQo+ID4g dGhlIHByaW1hcnkgdXNlLWNhc2UsIG9yIHRoYXQgaXQgZXZlbiBoYXBwZW5zIGluIHByYWN0aWNl IGluIHRoZSANCj4gPiByZWFsIHdvcmxkLiAgSXQncyBqdXN0IGFuIGV4YW1wbGUgcGVvcGxlIHVz ZSBpbiBwdWJsaWMgZm9ydW1zIHN1Y2ggDQo+ID4gYXMgdGhpcywgYXMgdG8gd2h5IG9uZSBuZWVk cyB0byBiZSBhYmxlIHRvIGhpZGUgc3VjaCB0aGluZ3MuDQo+ID4gDQo+ID4gVGhlIGlzc3VlIGlz bid0IGFib3V0IHRoZSBOU0EgbmVjZXNzYXJpbHkgLSB0aGUgaXNzdWUgaXMgZW1wbG95ZWVzIA0K PiA+IGF0IHRoZSBjYXJyaWVycyBhbG9uZyB0aGUgcGF0aC4gIENEUnMgYXJlIHZpZXdhYmxlIGJ5 IHRvbyBtYW55IA0KPiA+IGVtcGxveWVlcywgaW4gdG9vIG1hbnkgY2FycmllcnMgYWxvbmcgdGhl IGNhbGwgcGF0aC4NCj4gPiANCj4gPiBTYWZlIGhvdXNlcyAocGxhY2VzIHRvIGhpZGUgaW5mb3Jt YW50cy93aXRuZXNzZXMpIGFyZSBtZWFudCB0byBzdGF5IA0KPiA+IHNhZmUgYW5kIGFub255bW91 cywgb2J2aW91c2x5IC0gaW4gcGFydGljdWxhciBmcm9tIGxhcmdlIGNyaW1pbmFsIA0KPiA+IG9y Z2FuaXphdGlvbnMgd2l0aCBwbGVudHkgb2YgbW9uZXksIHBlb3BsZSwgYW5kIG11c2NsZSBwb3dl ci4gIEluIA0KPiA+IHRoZSBGQkkncyBjYXNlLCBmb3IgZXhhbXBsZSwgdGhleSBuZWVkIHRvIHBy b3RlY3Qgc2FmZSBob3VzZXMgZXZlbiANCj4gPiBmcm9tIG90aGVyIGdvdmVybm1lbnQgb3JnYW5p emF0aW9ucyB0aGV5IG1pZ2h0IGJlIGludmVzdGlnYXRpbmcvDQo+ID4gcHJvc2VjdXRpbmcuICBU aGV5IGhhdmUgdG8gZGlzdHJ1c3QgZWFjaCBvdGhlciwgZm9yIGdvb2QgcmVhc29uLiANCj4gPiBT aW5jZSB5b3UncmUgaW4gREMsIHlvdSBrbm93IHRoaXMgYmV0dGVyIHRoYW4gbWUuIDopDQo+ID4g DQo+ID4gU28gaWYgeW91J3JlIGFuIEZCSSBvZmZpY2UvYWdlbnQvU0FDIG9yIHdoYXRldmVyLCBh bmQgeW91IG5lZWQgdG8gDQo+ID4gdGFsayB0byB0aGUgc2FmZSBob3VzZSByZWd1bGFybHksIHlv dSBkb24ndCB3YW50IHRvIGxlYXZlIGEgdHJhY2UgaW4NCj4gPiBDRFJzIG9mIHlvdXIgY2FsbGlu ZyBwYXJ0eSBudW1iZXIuLi4gYmVjYXVzZSB0aGVuIHNvbWVvbmUgd2hvIGtub3dzIA0KPiA+IHdo byB0aGUgb2ZmaWNlL1NBQyBpcyBmb3IgYSBjYXNlLCBhbmQgdGhlaXIgcGhvbmUgbnVtYmVyLCBj YW4gZ2V0IGEgDQo+ID4gaG9sZCBvZiBDRFJzIGFuZCBsb29rIGZvciB3aG8gdGhhdCBvZmZpY2Uv U0FDIGlzIGNhbGxpbmcsIGFuZCB0aGVuIA0KPiA+IGZpZ3VyZSBvdXQgdGhlIG51bWJlciB0byB0 aGUgc2FmZSBob3VzZS4gIE9yIHZpY2UgdmVyc2EsIGlmIHRoZSBTYWZlDQo+ID4gSG91c2UgY2Fs bHMgdGhlIFNBQywgdGhlIENEUnMgc2hvdyBjYWxscyB0byB0aGUgU0FDIGZyb20gYSBzYWZlLQ0K PiA+IGhvdXNlIG51bWJlci4gKGFnYWluLCBJIGNhbid0IHJlbWVtYmVyIHdoaWNoIGNhbGwgZGly ZWN0aW9uIHdhcyB0aGUgDQo+ID4gb25lIHVzZWQgaW4gdGhlIGV4YW1wbGUgSSdkIGhlYXJkLCBv ciBpZiBpdCdzIGJvdGggd2F5cykgIE9uY2UgeW91IA0KPiA+IGhhdmUgcG90ZW50aWFsIFNhZmUt SG91c2UgcGhvbmUgbnVtYmVycywgaXQncyBub3QgaGFyZCB0byB0cmFjayBkb3duDQo+ID4gbG9j YXRpb24sIHNpbmNlIHRoZSB3aG9sZSBwcmVtaXNlIGhlcmUgaXMgeW91IGhhdmUgdGhlIG1vbmV5 L3Bvd2VyIA0KPiA+IHRvIGNvLW9wdCBlbXBsb3llZXMgYXQgY2FycmllcnMuDQo+ID4gDQo+ID4g QWdhaW4sIEkgaGF2ZSBubyBpZGVhIGlmIHRoaXMgaXMgd2hhdCByZWFsbHkgZHJpdmVzIHRoZSBu ZWVkIC0gaXQncyANCj4gPiBqdXN0IGFuIGV4YW1wbGUgSSd2ZSBiZWVuIHRvbGQgaW4gb3RoZXIg cHVibGljIGZvcmEuDQo+ID4gDQo+ID4gV2UgZG8gc2ltaWxhciB0aGluZ3MgZm9yIExhd2Z1bCBJ bnRlcmNlcHQsIGZvciB3aGljaCB0aGUgDQo+ID4gcmVxdWlyZW1lbnRzIGFuZCBtZWNoYW5pc21z IGFyZSBwdWJsaWNseSBrbm93bi9kb2N1bWVudGVkIGZvciANCj4gPiBzZXZlcmFsIGNvdW50cmll cyAtIG5vdCBhbGwgY291bnRyaWVzIGhhdmUgdGhlIHNhbWUgcnVsZXMgb3IgDQo+ID4gbWVjaGFu aXNtcywgYnV0IHRoZXkncmUgZ2VuZXJhbGx5IHNpbWlsYXIuICBObyBDRFIgZW50cmllcyBhcmUg DQo+ID4gcmVjb3JkZWQvZ2VuZXJhdGVkIGFib3V0IHdobydzIHVuZGVyIHdhcnJhbnQsIGJlaW5n IHdpcmV0YXBwZWQgcGFzdC8NCj4gPiBwcmVzZW50L2Z1dHVyZSwgZXRjLiAgSWYgeW91IGxvb2tl ZCBhdCBhIENEUiBmb3IgYSB3aXJldGFwcGVkIGNhbGwsIA0KPiA+IG5vdGhpbmcgd291bGQgYXBw ZWFyIGRpZmZlcmVudCBmcm9tIGEgcmVndWxhciBjYWxsLg0KPiA+IA0KPiA+IC1oYWRyaWVsDQo+ ID4gDQo+ID4gDQo+ID4gT24gQXVnIDYsIDIwMTMsIGF0IDY6MTMgUE0sIFJpY2hhcmQgU2hvY2tl eSA8cmljaGFyZEBzaG9ja2V5LnVzPiANCndyb3RlOg0KPiA+IA0KPiA+ID4gDQo+ID4gPiBPSyAu LiBzbyB0aGUgRkJJIG9yIENJQSBkb2Vzbid0IHdhbnQgdGhlIE5TQSB0byBrbm93IHdobyB0aGV5 IA0KPiBhcmUgY2FsbGluZz8gDQo+ID4gPiANCj4gPiA+IFNvcnJ5IGl0cyBjb2NrdGFpbCBob3Vy IG9uIHRoZSBVUyBlYXN0IGNvYXN0Lg0KPiA+ID4gDQo+ID4gPiBJIHNodWRkZXIgdGhpbmtpbmcg YWJvdXQgdGhlIGNvcm5lciBjYXNlcyBoZXJlIG5lZWQgdG8gYmUgbGlzdGVkaW4gDQpkZXRhaWwu DQo+ID4gPiAuLi4uIDxzaWdoPiANCj4gPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+IEZyb206IEhhZHJpZWwgS2FwbGFuIFttYWlsdG86aGFkcmllbC5rYXBsYW5A b3JhY2xlLmNvbV0gDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDYsIDIwMTMgNjowMyBQ TQ0KPiA+ID4gVG86IFJpY2hhcmQgU2hvY2tleQ0KPiA+ID4gQ2M6IHN0aXJAaWV0Zi5vcmcNCj4g PiA+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gRWFybHkgSG9tZXdvcmsgKHdhcyBSZTogTW92aW5nIGZy b20gQk9GIHRvIA0KQ2hhcnRlcikNCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBFeGFtcGxlOiBhbiBG Qkkgb2ZmaWNlIG9yIGFnZW50IGNhbGxzIGEgc2FmZSBob3VzZS4NCj4gPiA+IA0KPiA+ID4gLWhh ZHJpZWwNCj4gPiA+IA0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gc3RpciBtYWlsaW5nIGxpc3QNCj4gPiBzdGlyQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo= --=_alternative 0054F21885257BC0_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPiZxdW90OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5lcXVpdmFsZW50DQp0byB3aGF0IGl0IChzaWMpIHByb3ZpZGVkIGluIHRoZSBQ U1ROIHRvZGF5PGI+IDwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mcXVvdDsN CjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O0R3aWdodCwgVGltb3Ro eSBNIChUaW0pJnF1b3Q7ICZsdDt0aW1vdGh5LmR3aWdodEB2ZXJpem9uLmNvbSZndDsNCndyb3Rl IG9uIDA4LzA3LzIwMTMgMTE6MTM6MDYgQU06PGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmcXVvdDtE d2lnaHQsIFRpbW90aHkgTSAoVGltKSZxdW90OyAmbHQ7dGltb3RoeS5kd2lnaHRAdmVyaXpvbi5j b20mZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRvOiBKYW5ldCBQ IEd1bm4vVVNBL0NTQ0BDU0MsIEhhZHJpZWwgS2FwbGFuDQombHQ7aGFkcmllbC5rYXBsYW5Ab3Jh Y2xlLmNvbSZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQ2M6ICZx dW90O3N0aXJAaWV0Zi5vcmcmcXVvdDsgJmx0O3N0aXJAaWV0Zi5vcmcmZ3Q7LA0KJnF1b3Q7c3Rp ci1ib3VuY2VzQGlldGYub3JnJnF1b3Q7ICZsdDtzdGlyLTxicj4NCiZndDsgYm91bmNlc0BpZXRm Lm9yZyZndDssIFJpY2hhcmQgU2hvY2tleSAmbHQ7cmljaGFyZEBzaG9ja2V5LnVzJmd0OzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBEYXRlOiAwOC8wNy8yMDEzIDExOjE0 IEFNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFN1YmplY3Q6IFJFOiBb c3Rpcl0gRWFybHkgSG9tZXdvcmsgJm5ic3A7KHdhcw0KUmU6ICZuYnNwO01vdmluZyBmcm9tIEJP RiB0byBDaGFydGVyKTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7IEphbmV0LDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSWRlYWxseSB0aGUgbnVt YmVyIHNlbnQgd291bGQgYWxsb3cgdXMgdG8gaWRlbnRpZnkNCnRoZSBiaWxsYWJsZSA8YnI+DQom Z3Q7IHBhcnR5IGV2ZW4gaWYgaXQgZG9lc27igJl0IGlkZW50aWZ5IHRoZSBsb2NhdGlvbiBmcm9t IHdoaWNoIHRoZSBjYWxsDQo8YnI+DQomZ3Q7IHdhcyBzZW50IG9yIHRoZSBpbmRpdmlkdWFsIHRo YXQgc2VudCBpdC4gJm5ic3A7SXMgdGhhdCBjb25zaXN0ZW50DQp3aXRoIDxicj4NCiZndDsgeW91 ciDigJxmYWtlIG51bWJlcuKAnSBpZGVhPzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgdGlt PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBzdGlyLWJvdW5jZXNAaWV0Zi5vcmcg WzwvZm9udD48L3R0PjxhIGhyZWY9Im1haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmciPjx0dD48 Zm9udCBzaXplPTI+bWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZzwvZm9udD48L3R0PjwvYT48 dHQ+PGZvbnQgc2l6ZT0yPl0NCk9uIEJlaGFsZiBPZiA8YnI+DQomZ3Q7IEphbmV0IFAgR3Vubjxi cj4NCiZndDsgU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDcsIDIwMTMgNzowOSBBTTxicj4NCiZn dDsgVG86IEhhZHJpZWwgS2FwbGFuPGJyPg0KJmd0OyBDYzogc3RpckBpZXRmLm9yZzsgc3Rpci1i b3VuY2VzQGlldGYub3JnOyBSaWNoYXJkIFNob2NrZXk8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBb c3Rpcl0gRWFybHkgSG9tZXdvcmsgKHdhcyBSZTogTW92aW5nIGZyb20gQk9GIHRvIENoYXJ0ZXIp PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFRoYXQgaXMgbm90IHRoZSBz cGVjaWZpYyBjYXNlIEkgd2FzIHRoaW5raW5nIG9mLCBidXQgaXQgc3VmZmljZXMgYXMNCjxicj4N CiZndDsgYW4gZXhhbXBsZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFlvdSBkbyBub3Qgd2FudCBj YXJyaWVyIGVtcGxveWVlcyAod2hvIGhhdmUgbGVnaXRpbWF0ZSByZWFzb25zIHRvDQo8YnI+DQom Z3Q7IGxvb2sgYXQgQ0RScywgYnV0IGRvIG5vdCB0eXBpY2FsbHkgaGF2ZSBzZWN1cml0eSBjbGVh cmFuY2VzKSB0byBrbm93PGJyPg0KJmd0OyB3aGVyZSBwYXJ0aWN1bGFyIHBob25lIGNhbGxzIGFy ZSBjb21pbmcgZnJvbS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90O0Zha2UgbnVtYmVycyZx dW90OyBzaG91bGQgYmUgc3VmZmljaWVudC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhpbmsg dGhlIHJlZmVyZW5jZSBpbiB0aGUgY2hhcnRlciB0byAmcXVvdDtlcXVpdmFsZW50IHRvIHdoYXQg aXQNCihzaWMpPGJyPg0KJmd0OyBwcm92aWRlZCBpbiB0aGUgUFNUTiB0b2RheSAmcXVvdDsgY292 ZXJzIGl0LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSmFuZXQgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IHN0aXItYm91bmNlc0BpZXRmLm9yZyB3cm90ZSBvbiAwOC8wNi8yMDEzIDA3OjAwOjE4IFBNOjxi cj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEZyb206IEhhZHJpZWwgS2FwbGFuICZsdDtoYWRyaWVs LmthcGxhbkBvcmFjbGUuY29tJmd0OyA8YnI+DQomZ3Q7ICZndDsgVG86IFJpY2hhcmQgU2hvY2tl eSAmbHQ7cmljaGFyZEBzaG9ja2V5LnVzJmd0OyA8YnI+DQomZ3Q7ICZndDsgQ2M6IHN0aXJAaWV0 Zi5vcmcgPGJyPg0KJmd0OyAmZ3Q7IERhdGU6IDA4LzA2LzIwMTMgMDc6MDAgUE0gPGJyPg0KJmd0 OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbc3Rpcl0gRWFybHkgSG9tZXdvcmsgJm5ic3A7KHdhcyBSZTog Jm5ic3A7TW92aW5nDQpmcm9tIEJPRiB0byBDaGFydGVyKSA8YnI+DQomZ3Q7ICZndDsgU2VudCBi eTogc3Rpci1ib3VuY2VzQGlldGYub3JnIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IEFjdHVhbGx5LCBJIGFsd2F5cyBmb3JnZXQgd2hpY2ggY2FsbCBkaXJl Y3Rpb24gdGhpcyBuZWVkcyB0bw0KaGFwcGVuIDxicj4NCiZndDsgJmd0OyBpbiAtIG9yIG1heWJl IGl0IG5lZWRzIHRvIGhhcHBlbiBpbiBib3RoIGRpcmVjdGlvbnMuICZuYnNwO0J1dA0KdGhpcyBp cyA8YnI+DQomZ3Q7ICZndDsganVzdCBhbiBleGFtcGxlIGFueXdheSwgb2Ygb25lIHJlYXNvbiBh IGdvdmVybm1lbnQgbWlnaHQgd2FudA0KdG8gPGJyPg0KJmd0OyAmZ3Q7IGhpZGUgdGhlIHJlYWwg Y2FsbGluZyBwYXJ0eSBudW1iZXIgZnJvbSBDRFJzLiAmbmJzcDtJJ20gbm90IHNheWluZw0KaXQn cyA8YnI+DQomZ3Q7ICZndDsgdGhlIHByaW1hcnkgdXNlLWNhc2UsIG9yIHRoYXQgaXQgZXZlbiBo YXBwZW5zIGluIHByYWN0aWNlIGluDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7IHJlYWwgd29ybGQuICZu YnNwO0l0J3MganVzdCBhbiBleGFtcGxlIHBlb3BsZSB1c2UgaW4gcHVibGljIGZvcnVtcw0Kc3Vj aCA8YnI+DQomZ3Q7ICZndDsgYXMgdGhpcywgYXMgdG8gd2h5IG9uZSBuZWVkcyB0byBiZSBhYmxl IHRvIGhpZGUgc3VjaCB0aGluZ3MuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGUg aXNzdWUgaXNuJ3QgYWJvdXQgdGhlIE5TQSBuZWNlc3NhcmlseSAtIHRoZSBpc3N1ZSBpcyBlbXBs b3llZXMNCjxicj4NCiZndDsgJmd0OyBhdCB0aGUgY2FycmllcnMgYWxvbmcgdGhlIHBhdGguICZu YnNwO0NEUnMgYXJlIHZpZXdhYmxlIGJ5IHRvbw0KbWFueSA8YnI+DQomZ3Q7ICZndDsgZW1wbG95 ZWVzLCBpbiB0b28gbWFueSBjYXJyaWVycyBhbG9uZyB0aGUgY2FsbCBwYXRoLjxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgU2FmZSBob3VzZXMgKHBsYWNlcyB0byBoaWRlIGluZm9ybWFu dHMvd2l0bmVzc2VzKSBhcmUgbWVhbnQgdG8NCnN0YXkgPGJyPg0KJmd0OyAmZ3Q7IHNhZmUgYW5k IGFub255bW91cywgb2J2aW91c2x5IC0gaW4gcGFydGljdWxhciBmcm9tIGxhcmdlIGNyaW1pbmFs DQo8YnI+DQomZ3Q7ICZndDsgb3JnYW5pemF0aW9ucyB3aXRoIHBsZW50eSBvZiBtb25leSwgcGVv cGxlLCBhbmQgbXVzY2xlIHBvd2VyLg0KJm5ic3A7SW4gPGJyPg0KJmd0OyAmZ3Q7IHRoZSBGQkkn cyBjYXNlLCBmb3IgZXhhbXBsZSwgdGhleSBuZWVkIHRvIHByb3RlY3Qgc2FmZSBob3VzZXMNCmV2 ZW4gPGJyPg0KJmd0OyAmZ3Q7IGZyb20gb3RoZXIgZ292ZXJubWVudCBvcmdhbml6YXRpb25zIHRo ZXkgbWlnaHQgYmUgaW52ZXN0aWdhdGluZy88YnI+DQomZ3Q7ICZndDsgcHJvc2VjdXRpbmcuICZu YnNwO1RoZXkgaGF2ZSB0byBkaXN0cnVzdCBlYWNoIG90aGVyLCBmb3IgZ29vZA0KcmVhc29uLiAm bmJzcDs8YnI+DQomZ3Q7ICZndDsgU2luY2UgeW91J3JlIGluIERDLCB5b3Uga25vdyB0aGlzIGJl dHRlciB0aGFuIG1lLiA6KTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgU28gaWYgeW91 J3JlIGFuIEZCSSBvZmZpY2UvYWdlbnQvU0FDIG9yIHdoYXRldmVyLCBhbmQgeW91IG5lZWQNCnRv IDxicj4NCiZndDsgJmd0OyB0YWxrIHRvIHRoZSBzYWZlIGhvdXNlIHJlZ3VsYXJseSwgeW91IGRv bid0IHdhbnQgdG8gbGVhdmUgYSB0cmFjZQ0KaW48YnI+DQomZ3Q7ICZndDsgQ0RScyBvZiB5b3Vy IGNhbGxpbmcgcGFydHkgbnVtYmVyLi4uIGJlY2F1c2UgdGhlbiBzb21lb25lIHdobw0Ka25vd3Mg PGJyPg0KJmd0OyAmZ3Q7IHdobyB0aGUgb2ZmaWNlL1NBQyBpcyBmb3IgYSBjYXNlLCBhbmQgdGhl aXIgcGhvbmUgbnVtYmVyLCBjYW4NCmdldCBhIDxicj4NCiZndDsgJmd0OyBob2xkIG9mIENEUnMg YW5kIGxvb2sgZm9yIHdobyB0aGF0IG9mZmljZS9TQUMgaXMgY2FsbGluZywgYW5kDQp0aGVuIDxi cj4NCiZndDsgJmd0OyBmaWd1cmUgb3V0IHRoZSBudW1iZXIgdG8gdGhlIHNhZmUgaG91c2UuICZu YnNwO09yIHZpY2UgdmVyc2EsDQppZiB0aGUgU2FmZTxicj4NCiZndDsgJmd0OyBIb3VzZSBjYWxs cyB0aGUgU0FDLCB0aGUgQ0RScyBzaG93IGNhbGxzIHRvIHRoZSBTQUMgZnJvbSBhIHNhZmUtPGJy Pg0KJmd0OyAmZ3Q7IGhvdXNlIG51bWJlci4gKGFnYWluLCBJIGNhbid0IHJlbWVtYmVyIHdoaWNo IGNhbGwgZGlyZWN0aW9uIHdhcw0KdGhlIDxicj4NCiZndDsgJmd0OyBvbmUgdXNlZCBpbiB0aGUg ZXhhbXBsZSBJJ2QgaGVhcmQsIG9yIGlmIGl0J3MgYm90aCB3YXlzKSAmbmJzcDtPbmNlDQp5b3Ug PGJyPg0KJmd0OyAmZ3Q7IGhhdmUgcG90ZW50aWFsIFNhZmUtSG91c2UgcGhvbmUgbnVtYmVycywg aXQncyBub3QgaGFyZCB0byB0cmFjaw0KZG93bjxicj4NCiZndDsgJmd0OyBsb2NhdGlvbiwgc2lu Y2UgdGhlIHdob2xlIHByZW1pc2UgaGVyZSBpcyB5b3UgaGF2ZSB0aGUgbW9uZXkvcG93ZXINCjxi cj4NCiZndDsgJmd0OyB0byBjby1vcHQgZW1wbG95ZWVzIGF0IGNhcnJpZXJzLjxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgQWdhaW4sIEkgaGF2ZSBubyBpZGVhIGlmIHRoaXMgaXMgd2hh dCByZWFsbHkgZHJpdmVzIHRoZSBuZWVkDQotIGl0J3MgPGJyPg0KJmd0OyAmZ3Q7IGp1c3QgYW4g ZXhhbXBsZSBJJ3ZlIGJlZW4gdG9sZCBpbiBvdGhlciBwdWJsaWMgZm9yYS48YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IFdlIGRvIHNpbWlsYXIgdGhpbmdzIGZvciBMYXdmdWwgSW50ZXJj ZXB0LCBmb3Igd2hpY2ggdGhlIDxicj4NCiZndDsgJmd0OyByZXF1aXJlbWVudHMgYW5kIG1lY2hh bmlzbXMgYXJlIHB1YmxpY2x5IGtub3duL2RvY3VtZW50ZWQgZm9yDQo8YnI+DQomZ3Q7ICZndDsg c2V2ZXJhbCBjb3VudHJpZXMgLSBub3QgYWxsIGNvdW50cmllcyBoYXZlIHRoZSBzYW1lIHJ1bGVz IG9yDQo8YnI+DQomZ3Q7ICZndDsgbWVjaGFuaXNtcywgYnV0IHRoZXkncmUgZ2VuZXJhbGx5IHNp bWlsYXIuICZuYnNwO05vIENEUiBlbnRyaWVzDQphcmUgPGJyPg0KJmd0OyAmZ3Q7IHJlY29yZGVk L2dlbmVyYXRlZCBhYm91dCB3aG8ncyB1bmRlciB3YXJyYW50LCBiZWluZyB3aXJldGFwcGVkDQpw YXN0Lzxicj4NCiZndDsgJmd0OyBwcmVzZW50L2Z1dHVyZSwgZXRjLiAmbmJzcDtJZiB5b3UgbG9v a2VkIGF0IGEgQ0RSIGZvciBhIHdpcmV0YXBwZWQNCmNhbGwsIDxicj4NCiZndDsgJmd0OyBub3Ro aW5nIHdvdWxkIGFwcGVhciBkaWZmZXJlbnQgZnJvbSBhIHJlZ3VsYXIgY2FsbC48YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC1oYWRyaWVsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gQXVnIDYsIDIwMTMsIGF0IDY6MTMgUE0sIFJpY2hhcmQg U2hvY2tleSAmbHQ7cmljaGFyZEBzaG9ja2V5LnVzJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9LIC4uIHNvIHRoZSBG Qkkgb3IgQ0lBIGRvZXNuJ3Qgd2FudCB0aGUgTlNBIHRvIGtub3cgd2hvDQp0aGV5IDxicj4NCiZn dDsgYXJlIGNhbGxpbmc/IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 IFNvcnJ5IGl0cyBjb2NrdGFpbCBob3VyIG9uIHRoZSBVUyBlYXN0IGNvYXN0Ljxicj4NCiZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgc2h1ZGRlciB0aGlua2luZyBhYm91dCB0 aGUgY29ybmVyIGNhc2VzIGhlcmUgbmVlZCB0byBiZQ0KbGlzdGVkaW4gZGV0YWlsLjxicj4NCiZn dDsgJmd0OyAmZ3Q7IC4uLi4gJmx0O3NpZ2gmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgRnJvbTogSGFkcmllbCBLYXBsYW4gWzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOmhh ZHJpZWwua2FwbGFuQG9yYWNsZS5jb20+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86aGFkcmllbC5r YXBsYW5Ab3JhY2xlLmNvbTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPl0NCjxicj4N CiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNiwgMjAxMyA2OjAzIFBNPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgVG86IFJpY2hhcmQgU2hvY2tleTxicj4NCiZndDsgJmd0OyAmZ3Q7 IENjOiBzdGlyQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtzdGly XSBFYXJseSBIb21ld29yayAod2FzIFJlOiBNb3ZpbmcgZnJvbQ0KQk9GIHRvIENoYXJ0ZXIpPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgRXhhbXBsZTogYW4gRkJJIG9mZmljZSBvciBhZ2VudCBjYWxscyBhIHNhZmUgaG91c2UuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLWhhZHJpZWw8YnI+DQomZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IHN0aXIgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IHN0aXJAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgPC9m b250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 aXI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N0aXI8L2ZvbnQ+PC90dD48L2E+DQo= --=_alternative 0054F21885257BC0_=-- From kent@bbn.com Wed Aug 7 13:57:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31AB21E80A9 for ; Wed, 7 Aug 2013 13:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFgULuRBTtre for ; Wed, 7 Aug 2013 13:57:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D20F621E8139 for ; Wed, 7 Aug 2013 13:57:35 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50917) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V7AnR-0008J5-JY; Wed, 07 Aug 2013 16:57:29 -0400 Message-ID: <5202B4B7.209@bbn.com> Date: Wed, 07 Aug 2013 16:57:27 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <52016AD5.6040306@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lucy Lynch , IETF STIR Mail List , Russ Housley Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:57:41 -0000 Brian, > I did misunderstand the text you proposed, but I do think there is a > difference between "blocked" and "never sent". Are you okay with > Russ's latest edits? I am. > > Brian there is ambiguity, since blocked very near the sender is more or less the same as never sent, but no need to discuss this further. At BBN we have PRI interfaces to the PSTN from our internal VoIP system, so there are a variety of interface options. Syeve From richard@shockey.us Wed Aug 7 14:29:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A30211E80FA for ; Wed, 7 Aug 2013 14:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.054 X-Spam-Level: X-Spam-Status: No, score=-102.054 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM0J571pit06 for ; Wed, 7 Aug 2013 14:29:14 -0700 (PDT) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id C029D21F9ADC for ; Wed, 7 Aug 2013 14:29:14 -0700 (PDT) Received: (qmail 23027 invoked by uid 0); 7 Aug 2013 21:28:50 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.mail.unifiedlayer.com with SMTP; 7 Aug 2013 21:28:50 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=bwfN+vJlEQL97FClOaGIRIyeE3DxvfhR3nlXDlX2gGQ=; b=FeO9oe491Pi8bvoRqGYc5/Zn4m3Kei5WBGY80tw7IEnQtCqdgFCVhLgATelyiwUzr35pZA0GXvVI9v0z31Kocsh7Ghim923vLxprN+BQ1e5DwIs5485uk4w2/urpfA+o; Received: from [71.114.100.16] (port=56863 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V7BHl-0003F5-ON; Wed, 07 Aug 2013 15:28:49 -0600 From: "Richard Shockey" To: "'Stephen Kent'" , References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <52016AD5.6040306@bbn.com> <5202B4B7.209@bbn.com> In-Reply-To: <5202B4B7.209@bbn.com> Date: Wed, 7 Aug 2013 17:28:47 -0400 Message-ID: <01af01ce93b5$1ad84db0$5088e910$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQDqwCnHAPUadagCJzGJKQJY7sxNAN2QJYABfgbkrQIFt5oHmFrrbuA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 21:29:19 -0000 What ...no SIP Trunking?? Hummmm :-) -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, August 07, 2013 4:57 PM To: Brian Rosen Cc: Lucy Lynch; IETF STIR Mail List; Russ Housley Subject: Re: [stir] Moving from BOF to Charter Brian, > I did misunderstand the text you proposed, but I do think there is a > difference between "blocked" and "never sent". Are you okay with > Russ's latest edits? I am. > > Brian there is ambiguity, since blocked very near the sender is more or less the same as never sent, but no need to discuss this further. At BBN we have PRI interfaces to the PSTN from our internal VoIP system, so there are a variety of interface options. Syeve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From lynch@isoc.org Thu Aug 8 12:21:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7057221F9D4F for ; Thu, 8 Aug 2013 12:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUinBDx3wgaT for ; Thu, 8 Aug 2013 12:21:22 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id AC57021F8475 for ; Thu, 8 Aug 2013 12:21:20 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id r78JLBuX012787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Aug 2013 12:21:12 -0700 (PDT) (envelope-from lynch@isoc.org) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id r78JL8J9012776; Thu, 8 Aug 2013 12:21:11 -0700 (PDT) (envelope-from lynch@isoc.org) Date: Thu, 8 Aug 2013 12:21:08 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Russ Housley In-Reply-To: <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> Message-ID: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============3441445846387166770==" X-Mailman-Approved-At: Thu, 08 Aug 2013 13:20:07 -0700 Cc: Lucy Lynch , IETF STIR Mail List , Stephen Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: lynch@isoc.org List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:21:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============3441445846387166770== Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII On Tue, 6 Aug 2013, Russ Housley wrote: > Merging suggestions from other, I come up with: > > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. A called > party will receive an indication that the source telephone number has > been blocked to provide anonymity. This working group, to the extent > feasible, will specify privacy-friendly mechanisms that do not reveal > any more information to third parties than a call that does not make > use of secure telephone identification mechanisms. > > Does that work for you? I have some continuing concerns but will stand back for now and see how this develops. - Lucy > Russ > > > On Aug 6, 2013, at 5:03 PM, Stephen Kent wrote: > >> Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not eliminate this capability. A called party will receive an indication that the number of the caller has been blocked, in support of anonymity, equivalent to what it provided in the PSTN today. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of secure telephone identification mechanisms. > > --===============3441445846387166770== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --===============3441445846387166770==-- From ietf@meetecho.com Thu Aug 1 02:07:09 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744BE21F9A90 for ; Thu, 1 Aug 2013 02:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q97yvOzK4WCs for ; Thu, 1 Aug 2013 02:07:04 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpdg2.aruba.it [62.149.158.232]) by ietfa.amsl.com (Postfix) with ESMTP id C3D5121F84B1 for ; Thu, 1 Aug 2013 02:06:35 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6a1m01A0EaGCq01M6byW; Thu, 01 Aug 2013 11:06:35 +0200 Date: Thu, 1 Aug 2013 11:06:32 +0200 (CEST) From: Meetecho Team To: stir@ietf.org Message-ID: <1414153170.17.1375347992913.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16_1188374610.1375347992909" X-Mailman-Approved-At: Thu, 08 Aug 2013 13:20:08 -0700 Subject: [stir] STIR session recording available X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:07:09 -0000 ------=_Part_16_1188374610.1375347992909 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the STIR WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#STIR For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_16_1188374610.1375347992909-- From br@brianrosen.net Thu Aug 8 13:49:54 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DBA11E822A for ; Thu, 8 Aug 2013 13:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.738 X-Spam-Level: X-Spam-Status: No, score=-102.738 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8wDTbULqVLI for ; Thu, 8 Aug 2013 13:49:48 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id B57CF11E8136 for ; Thu, 8 Aug 2013 13:49:48 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so4050381pad.0 for ; Thu, 08 Aug 2013 13:49:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XjZwSgIACn0NrNN+DWraL1MjzjQGB+xALiTpaABkZjY=; b=iQwZKemRt7+Hh7qYHCgA85L8X6cOL/+Khn6unVXmzbYX3e5ZLbRlofAwXW0xfYEXvB 7P+WKjMlz+y1jXEZoom4KTsk/XHGnD+mkmF43Y5qM9KHhjIHpzjmVAXcrdNjL4sgyQlP hmO13a2YKXAHpkbZgRH8O6VtEUTyRXZMTWFW4KCHCIEJ+/eQ3tl69zpUsxkpEedU3jZr BZnzJlTaDffpbm6YYMwxQfRAZOD25RRaBp1AthRRUJfedL5pqYCpGzAOQa95yyMs2EBU BvA13dSxpM9nqMJmiwE7Hx18uWi1NTXixxFbmGEyjZzz330v2t6D9ZPTpCjgNZYsefsU 7kTw== X-Gm-Message-State: ALoCoQnYIII8SLkL+OG36AAvLlvn+9wRzWy/loBT5Xzh0gqFH+ZnIsJ3MSmjyVShUCwtzTM/fh2Q MIME-Version: 1.0 X-Received: by 10.68.12.97 with SMTP id x1mr7818418pbb.150.1375994984604; Thu, 08 Aug 2013 13:49:44 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Thu, 8 Aug 2013 13:49:44 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> Date: Thu, 8 Aug 2013 16:49:44 -0400 Message-ID: From: Brian Rosen To: "lynch@isoc.org" Content-Type: multipart/alternative; boundary=bcaec5215f914537ee04e375ccab Cc: IETF STIR Mail List , Russ Housley , Stephen Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:49:54 -0000 --bcaec5215f914537ee04e375ccab Content-Type: text/plain; charset=ISO-8859-1 Thanks. Is that it? Is everyone okay with the charter language now? Russ will post a new complete version just to make sure, but can we send this to the IESG and ask for the work group? Brian On Thursday, August 8, 2013, Lucy Lynch wrote: > On Tue, 6 Aug 2013, Russ Housley wrote: > > Merging suggestions from other, I come up with: >> >> Authentication and authorization of identity is closely linked to >> privacy, and these security features sometimes come at the cost of >> privacy. Anonymous calls are already defined in SIP standards, and this >> working group will not propose changes to these standards. A called >> party will receive an indication that the source telephone number has >> been blocked to provide anonymity. This working group, to the extent >> feasible, will specify privacy-friendly mechanisms that do not reveal >> any more information to third parties than a call that does not make >> use of secure telephone identification mechanisms. >> >> Does that work for you? >> > > I have some continuing concerns but will stand back for now and see > how this develops. > > - Lucy > > Russ >> >> >> On Aug 6, 2013, at 5:03 PM, Stephen Kent wrote: >> >> Authentication and authorization of identity is closely linked to >>> privacy, and these security features sometimes come at the cost of privacy. >>> Anonymous calls are already defined in SIP standards, and this working >>> group will not eliminate this capability. A called party will receive an >>> indication that the number of the caller has been blocked, in support of >>> anonymity, equivalent to what it provided in the PSTN today. This working >>> group, to the extent feasible, will specify privacy-friendly mechanisms >>> that do not reveal any more information to third parties than a call that >>> does not make use of secure telephone identification mechanisms. >>> >> >> --bcaec5215f914537ee04e375ccab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks.

Is that it? =A0Is everyone okay with the charter= language now? =A0Russ will post a new complete version just to make sure, = but can we send this to the IESG and ask for the work group?

=
Brian

On Thursday, August 8, 2013, Lucy Lynch wro= te:
On Tue, 6 Aug 2013, Russ Housley wrot= e:

Merging suggestions from other, I come up with:

Authentication and authorization of identity is closely linked to
privacy, and these security features sometimes come at the cost of
privacy. Anonymous calls are already defined in SIP standards, and this
working group will not propose changes to these standards. =A0A called
party will receive an indication that the source telephone number has
been blocked to provide anonymity. This working group, to the extent
feasible, will specify privacy-friendly mechanisms that do not reveal
any more information to third parties than a call that does not make
use of secure telephone identification mechanisms.

Does that work for you?

I have some continuing concerns but will stand back for now and see
how this develops.

- Lucy

Russ


On Aug 6, 2013, at 5:03 PM, Stephen Kent wrote:

Authentication and authorization of identity is closely linked to privacy, = and these security features sometimes come at the cost of privacy. Anonymou= s calls are already defined in SIP standards, and this working group will n= ot eliminate this capability. A called party will receive an indication tha= t the number of the caller has been blocked, in support of anonymity, equiv= alent to what it provided in the PSTN today. This working group, to the ext= ent feasible, will specify privacy-friendly mechanisms that do not reveal a= ny more information to third parties than a call that does not make use of = secure telephone identification mechanisms.

--bcaec5215f914537ee04e375ccab-- From eburger@standardstrack.com Thu Aug 8 16:54:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F9B11E8243 for ; Thu, 8 Aug 2013 16:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4-kaMpycnVE for ; Thu, 8 Aug 2013 16:54:07 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id D5FCE11E8176 for ; Thu, 8 Aug 2013 16:54:07 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a1k-0003lW-4d for stir@ietf.org; Thu, 08 Aug 2013 16:54:05 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_56550FE2-6F99-4E91-A32F-4BD8F6E00DFF"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <70F9EA32-EA60-4AAD-A653-3592C1F5691B@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 8 Aug 2013 19:53:59 -0400 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <01ca01ce92ef$eb60c5f0$c22251d0$@shockey.us> <1C73CF17-AF07-478D-8D27-49C3580BFE74@oracle.com> <01e501ce92f2$2b0398c0$810aca40$@shockey.us> <2B0F677F0B95454297753F58D4A07FA301298E31D8@FHDP1LUMXC7V31.us.one.verizon.com> To: stir@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 23:54:16 -0000 --Apple-Mail=_56550FE2-6F99-4E91-A32F-4BD8F6E00DFF Content-Type: multipart/alternative; boundary="Apple-Mail=_379839F1-63AC-408D-B4DA-084C89672AA7" --Apple-Mail=_379839F1-63AC-408D-B4DA-084C89672AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Which is storefront.com, which means the charter can be silent. On Aug 7, 2013, at 11:27 AM, Janet P Gunn wrote: >=20 >=20 > "equivalent to what it (sic) provided in the PSTN today "=20 >=20 > "Dwight, Timothy M (Tim)" wrote on = 08/07/2013 11:13:06 AM: >=20 > > From: "Dwight, Timothy M (Tim)" =20 > > To: Janet P Gunn/USA/CSC@CSC, Hadriel Kaplan = =20 > > Cc: "stir@ietf.org" , "stir-bounces@ietf.org" > bounces@ietf.org>, Richard Shockey =20 > > Date: 08/07/2013 11:14 AM=20 > > Subject: RE: [stir] Early Homework (was Re: Moving from BOF to = Charter)=20 > >=20 > > Janet,=20 > > =20 > > Ideally the number sent would allow us to identify the billable=20 > > party even if it doesn=92t identify the location from which the call=20= > > was sent or the individual that sent it. Is that consistent with=20 > > your =93fake number=94 idea?=20 > > =20 > > tim=20 > > =20 > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of=20 > > Janet P Gunn > > Sent: Wednesday, August 07, 2013 7:09 AM > > To: Hadriel Kaplan > > Cc: stir@ietf.org; stir-bounces@ietf.org; Richard Shockey > > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter)=20 > > =20 > >=20 > > That is not the specific case I was thinking of, but it suffices as=20= > > an example.=20 > >=20 > > You do not want carrier employees (who have legitimate reasons to=20 > > look at CDRs, but do not typically have security clearances) to know > > where particular phone calls are coming from.=20 > >=20 > > "Fake numbers" should be sufficient.=20 > >=20 > > I think the reference in the charter to "equivalent to what it (sic) > > provided in the PSTN today " covers it.=20 > >=20 > > Janet=20 > >=20 > > stir-bounces@ietf.org wrote on 08/06/2013 07:00:18 PM: > >=20 > > > From: Hadriel Kaplan =20 > > > To: Richard Shockey =20 > > > Cc: stir@ietf.org=20 > > > Date: 08/06/2013 07:00 PM=20 > > > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter)=20 > > > Sent by: stir-bounces@ietf.org=20 > > >=20 > > >=20 > > > Actually, I always forget which call direction this needs to = happen=20 > > > in - or maybe it needs to happen in both directions. But this is=20= > > > just an example anyway, of one reason a government might want to=20= > > > hide the real calling party number from CDRs. I'm not saying it's=20= > > > the primary use-case, or that it even happens in practice in the=20= > > > real world. It's just an example people use in public forums such=20= > > > as this, as to why one needs to be able to hide such things. > > >=20 > > > The issue isn't about the NSA necessarily - the issue is employees=20= > > > at the carriers along the path. CDRs are viewable by too many=20 > > > employees, in too many carriers along the call path. > > >=20 > > > Safe houses (places to hide informants/witnesses) are meant to = stay=20 > > > safe and anonymous, obviously - in particular from large criminal=20= > > > organizations with plenty of money, people, and muscle power. In=20= > > > the FBI's case, for example, they need to protect safe houses even=20= > > > from other government organizations they might be investigating/ > > > prosecuting. They have to distrust each other, for good reason. =20= > > > Since you're in DC, you know this better than me. :) > > >=20 > > > So if you're an FBI office/agent/SAC or whatever, and you need to=20= > > > talk to the safe house regularly, you don't want to leave a trace = in > > > CDRs of your calling party number... because then someone who = knows=20 > > > who the office/SAC is for a case, and their phone number, can get = a=20 > > > hold of CDRs and look for who that office/SAC is calling, and then=20= > > > figure out the number to the safe house. Or vice versa, if the = Safe > > > House calls the SAC, the CDRs show calls to the SAC from a safe- > > > house number. (again, I can't remember which call direction was = the=20 > > > one used in the example I'd heard, or if it's both ways) Once you=20= > > > have potential Safe-House phone numbers, it's not hard to track = down > > > location, since the whole premise here is you have the money/power=20= > > > to co-opt employees at carriers. > > >=20 > > > Again, I have no idea if this is what really drives the need - = it's=20 > > > just an example I've been told in other public fora. > > >=20 > > > We do similar things for Lawful Intercept, for which the=20 > > > requirements and mechanisms are publicly known/documented for=20 > > > several countries - not all countries have the same rules or=20 > > > mechanisms, but they're generally similar. No CDR entries are=20 > > > recorded/generated about who's under warrant, being wiretapped = past/ > > > present/future, etc. If you looked at a CDR for a wiretapped = call,=20 > > > nothing would appear different from a regular call. > > >=20 > > > -hadriel > > >=20 > > >=20 > > > On Aug 6, 2013, at 6:13 PM, Richard Shockey = wrote: > > >=20 > > > >=20 > > > > OK .. so the FBI or CIA doesn't want the NSA to know who they=20 > > are calling?=20 > > > >=20 > > > > Sorry its cocktail hour on the US east coast. > > > >=20 > > > > I shudder thinking about the corner cases here need to be = listedin detail. > > > > .... =20 > > > >=20 > > > > -----Original Message----- > > > > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 > > > > Sent: Tuesday, August 06, 2013 6:03 PM > > > > To: Richard Shockey > > > > Cc: stir@ietf.org > > > > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) > > > >=20 > > > >=20 > > > > Example: an FBI office or agent calls a safe house. > > > >=20 > > > > -hadriel > > > >=20 > > >=20 > > > _______________________________________________ > > > stir mailing list > > > stir@ietf.org > > > https://www.ietf.org/mailman/listinfo/stir = _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_379839F1-63AC-408D-B4DA-084C89672AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Which = is storefront.com, which means the = charter can be silent.

On Aug 7, 2013, at 11:27 AM, = Janet P Gunn <jgunn6@csc.com> = wrote:



"equivalent to what it (sic) provided in the PSTN today "

"Dwight, Timothy M (Tim)" <timothy.dwight@verizon.com&= gt; wrote on 08/07/2013 11:13:06 AM:

> From: "Dwight, Timothy M (Tim)" <timothy.dwight@verizon.com&= gt;
> To: Janet P Gunn/USA/CSC@CSC, Hadriel = Kaplan <hadriel.kaplan@oracle.com>= ;
> Cc: "stir@ietf.org" <stir@ietf.org>, "stir-bounces@ietf.org" = <stir-
> bounces@ietf.org>, = Richard Shockey <richard@shockey.us>
> Date: 08/07/2013 11:14 AM
> Subject: RE: [stir] Early Homework =  (was Re:  Moving from BOF to Charter)
>
> Janet,
>  
> Ideally the number sent would allow us to = identify the billable
> party even if it doesn=92t identify the location from which the = call
> was sent or the individual that sent it.  Is that consistent with
> your =93fake number=94 idea?
>  
> tim
>  
> From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On Behalf Of
> Janet P Gunn
> Sent: Wednesday, August 07, 2013 7:09 AM
> To: Hadriel Kaplan
> Cc: stir@ietf.org; stir-bounces@ietf.org; Richard = Shockey
> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter)
>  
>
> That is not the specific case I was thinking of, but it suffices as
> an example.
>
> You do not want carrier employees (who have legitimate reasons to
> look at CDRs, but do not typically have security clearances) to = know
> where particular phone calls are coming from.
>
> "Fake numbers" should be sufficient.
>
> I think the reference in the charter to "equivalent to what it (sic)
> provided in the PSTN today " covers it.
>
> Janet
>
> stir-bounces@ietf.org = wrote on 08/06/2013 07:00:18 PM:
>
> > From: Hadriel Kaplan <hadriel.kaplan@oracle.com>= ;
> > To: Richard Shockey <richard@shockey.us>
> > Cc: stir@ietf.org
> > Date: 08/06/2013 07:00 PM
> > Subject: Re: [stir] Early Homework  (was Re:  Moving from BOF to Charter)
> > Sent by: stir-bounces@ietf.org
> >
> >
> > Actually, I always forget which call direction this needs to happen
> > in - or maybe it needs to happen in both directions.  But this is
> > just an example anyway, of one reason a government might want to
> > hide the real calling party number from CDRs.  I'm not = saying it's
> > the primary use-case, or that it even happens in practice in the
> > real world.  It's just an example people use in public = forums such
> > as this, as to why one needs to be able to hide such = things.
> >
> > The issue isn't about the NSA necessarily - the issue is = employees
> > at the carriers along the path.  CDRs are viewable by too many
> > employees, in too many carriers along the call path.
> >
> > Safe houses (places to hide informants/witnesses) are meant to stay
> > safe and anonymous, obviously - in particular from large = criminal
> > organizations with plenty of money, people, and muscle power.  In
> > the FBI's case, for example, they need to protect safe houses even
> > from other government organizations they might be = investigating/
> > prosecuting.  They have to distrust each other, for good reason.  
> > Since you're in DC, you know this better than me. :)
> >
> > So if you're an FBI office/agent/SAC or whatever, and you need to
> > talk to the safe house regularly, you don't want to leave a = trace in
> > CDRs of your calling party number... because then someone who knows
> > who the office/SAC is for a case, and their phone number, can get a
> > hold of CDRs and look for who that office/SAC is calling, and then
> > figure out the number to the safe house.  Or vice versa, if the Safe
> > House calls the SAC, the CDRs show calls to the SAC from a = safe-
> > house number. (again, I can't remember which call direction = was the
> > one used in the example I'd heard, or if it's both ways) =  Once you
> > have potential Safe-House phone numbers, it's not hard to = track down
> > location, since the whole premise here is you have the = money/power
> > to co-opt employees at carriers.
> >
> > Again, I have no idea if this is what really drives the need - it's
> > just an example I've been told in other public fora.
> >
> > We do similar things for Lawful Intercept, for which the
> > requirements and mechanisms are publicly known/documented for
> > several countries - not all countries have the same rules or
> > mechanisms, but they're generally similar.  No CDR = entries are
> > recorded/generated about who's under warrant, being wiretapped past/
> > present/future, etc.  If you looked at a CDR for a = wiretapped call,
> > nothing would appear different from a regular call.
> >
> > -hadriel
> >
> >
> > On Aug 6, 2013, at 6:13 PM, Richard Shockey <richard@shockey.us> wrote:
> >
> > >
> > > OK .. so the FBI or CIA doesn't want the NSA to know who they
> are calling?
> > >
> > > Sorry its cocktail hour on the US east coast.
> > >
> > > I shudder thinking about the corner cases here need to be listedin detail.
> > > .... <sigh>
> > >
> > > -----Original Message-----
> > > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]
> > > Sent: Tuesday, August 06, 2013 6:03 PM
> > > To: Richard Shockey
> > > Cc: stir@ietf.org
> > > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)
> > >
> > >
> > > Example: an FBI office or agent calls a safe house.
> > >
> > > -hadriel
> > >
> >
> > _______________________________________________
> > stir mailing list
> > stir@ietf.org
> > https://www.ietf.org/mailman/listinfo/stir _______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_379839F1-63AC-408D-B4DA-084C89672AA7-- --Apple-Mail=_56550FE2-6F99-4E91-A32F-4BD8F6E00DFF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1MzYwWjAjBgkqhkiG9w0BCQQxFgQU +YISLAJeCnFIHmylb0K/xYJc+Y0wgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEACW7U4QWUKjQ2MjkxlGCZ5zI/1Raw2kLa82liwjXPnGnri5uWqFuu xE0MeYhUUpqidocgBaV9e6xKTWjxc/tQV/wAhUqrupAbUoh2MWYaOgbS5d2hviJi8BKfpYK0LcUL fJ7Nez43v6p6iKkiwyzvkchtaD/9mlxaJoJ5tc8gYUvDopPppBZKCQujFASm6ekA84O1D69A3g2S pxQsD9oLuXZgFLvf5tyLAgFtryX/X6BIi69M/4R3HXX7i5JYsBUV9a5LG7iOHk5PZps/uvZXSJ/R SLWquuPwv+Gxc0PX85PVVp98Gb59bPUyPxoAHKfi+4gGdiBIgHvSByY+H5HgHgAAAAAAAA== --Apple-Mail=_56550FE2-6F99-4E91-A32F-4BD8F6E00DFF-- From eburger@standardstrack.com Thu Aug 8 16:54:16 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC411E8176 for ; Thu, 8 Aug 2013 16:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhiq5QWkIzl7 for ; Thu, 8 Aug 2013 16:54:10 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id AD24811E816F for ; Thu, 8 Aug 2013 16:54:10 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a1t-0003lW-Vu; Thu, 08 Aug 2013 16:54:06 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_721B47FE-4625-4833-8B76-B9DC33BF0166"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric Burger In-Reply-To: <520160CD.5000306@bbn.com> Date: Thu, 8 Aug 2013 19:54:03 -0400 Message-Id: <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 23:54:17 -0000 --Apple-Mail=_721B47FE-4625-4833-8B76-B9DC33BF0166 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 *67 only blocks the delivery of the caller ID to the called party. The = network gets it, even often up to the called party's PBX. This relies on = the good graces of the PBX implementor to honor the privacy bit. On Aug 6, 2013, at 4:47 PM, Stephen Kent wrote: > Eric, >=20 > I don't think the privacy implications need to be that bad. After all = I think we > have assumed that callers will still be able to block caller ID info = when > making a VoIP call, in the same way that *67 works for called = initiated on the PSTN. > Also, unlisted PSTN numbers, by default, block their caller ID info. >=20 > Those seem like a reasonable starting point for VoIP caller ID = blocking requirements, > in the STIR context. >=20 >> I agree we are not looking at a national security private network = analysis. However, we are talking about the potential end of any privacy = or anonymity for ANY Internet application, more especially Internet = multimedia application. That needs to have a level of analysis that goes = beyond either "hopelessly broken" or "don't worry about it." >>=20 >=20 --Apple-Mail=_721B47FE-4625-4833-8B76-B9DC33BF0166 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1NDA0WjAjBgkqhkiG9w0BCQQxFgQU UY8lgsdqcu8T64Uo/XJ7jOjkAeswgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAIDkfMLNyfo/buEYf/KwQ4R+BknMKcwBb9kW6EmvIyT4HLI8QAHGR I6xun+wRnteGFWKtvNLG1M0Ouf4o0roWqLHOqC/n2h3bbi8TPBV1+k6upryhAWugqMyJuR0t8AT8 HK8SUWMkGyAhn7/V2iU7QYp2QO3aNvTUV3syuFtYcrF9dctzD5Z7OBVvy+LLfhbIYWhavGVEof8v aqQ9skfmx0N5hfovJTTPYqk5td7/e+9i9OHdeU3MHCXQgrFTvh0tXr72Oj6vmk//Yzb44G27zxaG isrLrYntneb541Txp/voIYWSek2jK4ctW8bF65Pn5VhsaIpz8tuTVtAkEEIcKwAAAAAAAA== --Apple-Mail=_721B47FE-4625-4833-8B76-B9DC33BF0166-- From eburger@standardstrack.com Thu Aug 8 16:54:27 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73A111E823E for ; Thu, 8 Aug 2013 16:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1y4F+ETuA1A for ; Thu, 8 Aug 2013 16:54:22 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id D487211E816F for ; Thu, 8 Aug 2013 16:54:18 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a1v-0003lW-Iw for stir@ietf.org; Thu, 08 Aug 2013 16:54:16 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_FB8845EE-25C8-48B4-9C43-4A5B6432950C"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 8 Aug 2013 19:54:07 -0400 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> <702EA082-43B7-490D-B909-00630A195CE4@vigilsec.com> <520114D6.2050205@dcrocker.net> <97FC9B06-AB16-46BE-B46F-B2E9576F0FF2@vigilsec.com> To: IETF STIR Mail List In-Reply-To: <97FC9B06-AB16-46BE-B46F-B2E9576F0FF2@vigilsec.com> X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 23:54:28 -0000 --Apple-Mail=_FB8845EE-25C8-48B4-9C43-4A5B6432950C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 6, 2013, at 1:12 PM, Russ Housley wrote: > Dave: >=20 >>> The threat document is quite different if it cover an in-band = mechanism or both an in-band and an out-of-band mechanism. Do you have = any thoughts on this? Do you have proposed charter text? >>=20 >> No doubt it's my naivete about the technical side of security work, = but it isn't obvious to me why your assertion is correct. Please = explain the nature of the differences that you see. >>=20 >> By way of example, imagine an out-of-band mechanism that merely takes = the in-band signature and stashes it somewhere, much like a cookie = mechanism. The storage environment can see the retrieval attributes in = the clear -- the same as any other transit handling node -- I suppose, = but the rest of the information won't be accessible to it. >>=20 >> Nevermind that, even before we have the charter saying that = out-of-band is to be deferred, we have yet-another introduction of it = into initial technical discussions. >=20 > The threat environment for in-band is simpler; it contains fewer = entities to consider in the analysis. >=20 > The threat environment for out-of-band is more complex; it contains = all of the entities in the in-band case as well as SBCs and PSTN = entities. I thought the justification for out-of-band is it avoided the SBC's, the = carriers, and so on. No? --Apple-Mail=_FB8845EE-25C8-48B4-9C43-4A5B6432950C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1NDA3WjAjBgkqhkiG9w0BCQQxFgQU qduR7zWcOW4tauBvVKnHsBvSOmwwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAYUmNr7xhVKsXpfQDWqVkCQ4f1R5NCzyDt8Gu0AslzMrSyCxf5zu0 6tBIqDtyzcvXDq8BLOB4OfAechV1hi+zbDETQdhgmDN4L/oQZP8NxsHHwqkO6mvwR9amQT3juxGa JSw6l4ZYJvoQaQ7G2TnsnZb1lXQR0toe320mTX+FRax6EFBnW2b/N9CF+AmOBbPbg/OTD2CO2ceF w1//lj9pPvPomb3EVG/eWlpPmXYWrQPDX7kfIs8JF9j5trp87oPYIOSmi79DXICdpE52U9eJ0kPk y1KSM1syGR/NNqmMCBAFnLlaL0RwZo3KhvLHqFds9eMA59ZLwoSyl2J6bL6nRwAAAAAAAA== --Apple-Mail=_FB8845EE-25C8-48B4-9C43-4A5B6432950C-- From eburger@standardstrack.com Thu Aug 8 16:54:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91B11E8179 for ; Thu, 8 Aug 2013 16:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.05 X-Spam-Level: X-Spam-Status: No, score=-101.05 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYUiV1jf8T6F for ; Thu, 8 Aug 2013 16:54:25 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC711E8176 for ; Thu, 8 Aug 2013 16:54:21 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a26-0003lW-U1 for stir@ietf.org; Thu, 08 Aug 2013 16:54:19 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_D8F6BAF1-0DF4-4313-9A9D-60625D461858"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 8 Aug 2013 19:54:10 -0400 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> To: stir@ietf.org In-Reply-To: <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 23:54:31 -0000 --Apple-Mail=_D8F6BAF1-0DF4-4313-9A9D-60625D461858 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan = wrote: > On Aug 5, 2013, at 4:36 PM, Eric Burger = wrote: > I agree we are not looking at a national security private network = analysis. However, we are talking about the potential end of any privacy = or anonymity for ANY Internet application, more especially Internet = multimedia application. >=20 > How so? Obviously we could theoretically create some mechanism that = took all call information from/to everyone and posted it to wikileaks or=20= > whatever, but I don't think we're that stupid. (nor do I think it = would get published by the IETF, nor would anyone use it if we did) >=20 > No one is proposing, for example, that anonymous calls no longer = remain anonymous. Nor that one can't make anonymous calls. Actually, we are. We are talking about "official" calling. Otherwise, we = would have p2psip and there would not be regulators in the middle. It = would not be hard to imaging regulators banning anonymous calling, as = the bad guys all use anonymous calling and grandpa still answers the = call and hands over his life savings to the nice lady on the phone. After that, what stops the regulators from congratulating the IETF on = doing such a good job on phone calls to extend it to email? And then to = IM? And then to TOR? > Your statement seems a bit alarmist. Ringing off the walls! >=20 > -hadriel >=20 --Apple-Mail=_D8F6BAF1-0DF4-4313-9A9D-60625D461858 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1NDExWjAjBgkqhkiG9w0BCQQxFgQU Y50FaB5Vc+zNbhPymi1t55YRrCAwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAGvUjY8UOW006fdVEOLfIh6VMnXq0GT5diOb/PwkCQLHrzAaJln6q YhwnoWPbk2pmns4XL4U2BEypYnYMX2CTen7Ur60tCPAFS4uTYAaVumGQAbh2X+AIbpD371bXy2b1 qYUE3ZoSAaU4bO+J0x+Vj+StObJwRShUAjAjnC2U0785SJU3L/2qfWMUWHs+urRZOUVfzDmPI7Ik k+7Jujx90JtUTI0nfCDkUx9qI3xMKJQd6DUqC8jSALRKzhoSYKWvCJsW3VUa8ktO/qvdjWr5UmdQ mPRU60Qfm3k4ByrkeLJXow1Kzu3Or9+bS8uBEfmTjFux37H6MOKRDyRDbdSAaQAAAAAAAA== --Apple-Mail=_D8F6BAF1-0DF4-4313-9A9D-60625D461858-- From hadriel.kaplan@oracle.com Thu Aug 8 19:01:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1410421F8F78 for ; Thu, 8 Aug 2013 19:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lejanx9J1tsA for ; Thu, 8 Aug 2013 19:01:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6447F11E8183 for ; Thu, 8 Aug 2013 19:01:33 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7921S34014010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 02:01:29 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7921Q2i003502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 02:01:27 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7921QMe018149; Fri, 9 Aug 2013 02:01:26 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 19:01:26 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> Date: Thu, 8 Aug 2013 22:01:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org, Stephen Kent Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 02:01:40 -0000 On Aug 8, 2013, at 7:54 PM, Eric Burger = wrote: > *67 only blocks the delivery of the caller ID to the called party. The = network gets it, even often up to the called party's PBX. This relies on = the good graces of the PBX implementor to honor the privacy bit. Yup, *67 blocks delivery. I believe that it's rare for it to be sent to = the called party's PBX, but I could be wrong on that. Regardless, we're = not making that any worse or better. If it works today, it will work = tomorrow. If it doesn't work today, we're not magically fixing it. True perfect source anonymity has never been a property of the PSTN: at = the very least, your local carrier knows who you are when you generate a = call. You can use cutouts, public phones, or buy a disposable phone at = the airport - and we're not preventing those things from being possible = - but in the general Grandma-at-home case, her local provider knows who = she is, even if she anonymizes her =46rom in her SIP UA phone today. = But that is not a problem we're tasked with solving, nor has it appeared = to even be a problem to begin with. Even for the Internet: at the very least, your local ISP knows your IP = Address, and knows you sent IP packets, and often knows where you sent = them to. You can use anonymous-proxies, public WiFi's, or whatever; but = in the general broadband subscriber case, your ISP knows.=20 -hadriel From hadriel.kaplan@oracle.com Thu Aug 8 20:24:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA3711E8192 for ; Thu, 8 Aug 2013 20:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7Ana+vEEahr for ; Thu, 8 Aug 2013 20:23:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 66DAC11E812E for ; Thu, 8 Aug 2013 20:23:55 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r793Nr4o030642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 03:23:54 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r793NqTW025770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 03:23:53 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r793NqXS027834; Fri, 9 Aug 2013 03:23:52 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 20:23:52 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> Date: Thu, 8 Aug 2013 23:23:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6A868569-552F-425B-A1AB-60149E17DFC6@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 03:24:02 -0000 On Aug 8, 2013, at 7:54 PM, Eric Burger = wrote: > On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan = wrote: >> No one is proposing, for example, that anonymous calls no longer = remain anonymous. Nor that one can't make anonymous calls. >=20 > Actually, we are. We are talking about "official" calling. Otherwise, = we would have p2psip and there would not be regulators in the middle. You lost me. I have no idea what p2psip has to do with anything. If = you think p2psip failed because it allows anonymous calls, you are waaay = off. You must mean something else, but I'm not getting it.(?) > It would not be hard to imaging regulators banning anonymous calling, = as the bad guys all use anonymous calling and grandpa still answers the = call and hands over his life savings to the nice lady on the phone. It's theoretically possible that such a thing could happen. I think = it's unlikely for regulators to do it, but people today are already = ignoring anonymous calls so it might be more of a result that no one = ever answers them, rather than regulatory mandate that carriers block = them. So what? Are we supposed to make people accept anonymous = communication requests if they don't want to? Should we be encouraging = spoofing in order to give attackers an incentive to not anonymize their = calls? Should we be just constantly randomizing source numbers for all = calls in the future, in order to protect the rights of those who don't = want their source number known? Should we just make all future calls be = anonymous? What's your proposed solution to such a dilemma? In some ways, getting to a stage of deployment where all bad guys use = anonymous numbers is a *good thing*. The fact is most users are already = conditioned to distrust anonymous calls, meaning the bad guys will have = a lower success rate, which means the fraud folks have an easier time = tracking the bad guys down. Ultimately, you *should* distrust anonymous = calls - you really do need to be more cautious, less trusting, etc. No? > After that, what stops the regulators from congratulating the IETF on = doing such a good job on phone calls to extend it to email? And then to = IM? And then to TOR? Ah yes, the old slippery-slope argument. I can play that game too. :) Using that logic: if we decide to not work on STIR because we're worried = that providing a mechanism for source identity verification means = governments will decide to prevent anonymous sources... then we should = shut down a whole bunch of stuff in the IETF, deprecate a crap-load of = RFCs, and retire to the beach. You could start with shutting down SCIM, = REPUTE, SAVI, KITTEN, DANE, OAUTH, and probably a few others (you can = never be too careful!). And of course immediately deprecate DKIM, = rfc4474, Mutual-TLS, any digest auth mechanism in any protocol, etc. I = mean if we provide a means of authenticating users, then governments = might not allow anonymous users, so we need to remove the mechanisms = from our specs. Right? At the end of the day we're the IETF, not ICANN or a government body. = They debate politics and policy. We solve technical problems. How are = we supposed to get anything accomplished, if we have to worry about = governments abusing their power and potentially taking advantage of = success of our mechanisms? -hadriel From ekr@rtfm.com Thu Aug 8 21:01:34 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4909521F9DDC for ; Thu, 8 Aug 2013 21:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.945 X-Spam-Level: X-Spam-Status: No, score=-102.945 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K15-MD4K8Tmm for ; Thu, 8 Aug 2013 21:01:28 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC3621F9DDB for ; Thu, 8 Aug 2013 21:01:28 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hu16so697855qab.3 for ; Thu, 08 Aug 2013 21:01:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wzzRFZY4xAFeZpFaOpX+GZz35cuoAkxdkW0957F2nlY=; b=JxDbGw1ByGCPMymrDCt1DkiGFupO7dd/28UnDePrqA+4bf+bL29FTD5GtDCZ+Y0YPw nBon7xw6/as7GjUE1VSS6dWf8yXMNxZ8B+QgApuo3Eckb6iuLrxSTQrt7xl9QA9zHij/ AU8w+C/n3+p2Z5glmBWXIjMj8RN9Hfqrh7jvqkaKy0XVwRr7nIxRESFNcrrdmQf5a7dG gvG0pyexNiwZ5V1Gd2ljmoeK6aNLKZbfkMlcpCaCOgunqo4ZbiNbu2fVul6MROeIXqyP yNfPsA9//zMN9OLpFpDcst3czFModNw1tGrDqaHFBgYlrJhYcAAbdG7hsSO993eK8HKi GbNQ== X-Gm-Message-State: ALoCoQnoMIqXFjkwN8s9uIayIVyth2BkcwMJg49AMxKB4id3eWsBuDtxSi1h7y8Zmczna5GfWC5y X-Received: by 10.229.150.16 with SMTP id w16mr2150925qcv.113.1376020886539; Thu, 08 Aug 2013 21:01:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Thu, 8 Aug 2013 21:00:46 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> From: Eric Rescorla Date: Thu, 8 Aug 2013 21:00:46 -0700 Message-ID: To: Eric Burger Content-Type: multipart/alternative; boundary=e89a8f6469ed25692a04e37bd4d0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 04:01:34 -0000 --e89a8f6469ed25692a04e37bd4d0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger wrote: > On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan > wrote: > > On Aug 5, 2013, at 4:36 PM, Eric Burger > wrote: > > I agree we are not looking at a national security private network > analysis. However, we are talking about the potential end of any privacy or > anonymity for ANY Internet application, more especially Internet multimedia > application. > > > > How so? Obviously we could theoretically create some mechanism that > took all call information from/to everyone and posted it to wikileaks or > > whatever, but I don't think we're that stupid. (nor do I think it would > get published by the IETF, nor would anyone use it if we did) > > > > No one is proposing, for example, that anonymous calls no longer remain > anonymous. Nor that one can't make anonymous calls. > > Actually, we are. We are talking about "official" calling. Otherwise, we > would have p2psip and there would not be regulators in the middle. It would > not be hard to imaging regulators banning anonymous calling, as the bad > guys all use anonymous calling and grandpa still answers the call and hands > over his life savings to the nice lady on the phone. > I'm not following this argument at all. The regulators could presumably require this now. How does STIR change the situation? -Ekr --e89a8f6469ed25692a04e37bd4d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger <<= a href=3D"mailto:eburger@standardstrack.com" target=3D"_blank">eburger@stan= dardstrack.com> wrote:
On Aug 6, 2013, at 6:50 AM= , Hadriel Kaplan <hadriel.k= aplan@oracle.com> wrote:
> On Aug 5, 2013, at 4:36 PM, Eric Burger <eburger@standardstrack.com> wrote:
> I agree we are not looking at a national security private network anal= ysis. However, we are talking about the potential end of any privacy or ano= nymity for ANY Internet application, more especially Internet multimedia ap= plication.
>
> How so? =A0Obviously we could theoretically create some mechanism that= took all call information from/to everyone and posted it to wikileaks or > whatever, but I don't think we're that stupid. (nor do I think= it would get published by the IETF, nor would anyone use it if we did)
>
> No one is proposing, for example, that anonymous calls no longer remai= n anonymous. =A0Nor that one can't make anonymous calls.

Actually, we are. We are talking about "official" calling. = Otherwise, we would have p2psip and there would not be regulators in the mi= ddle. It would not be hard to imaging regulators banning anonymous calling,= as the bad guys all use anonymous calling and grandpa still answers the ca= ll and hands over his life savings to the nice lady on the phone.
=A0
I'm not following this argument at all.= The regulators could presumably
require this now. How does STIR = change the situation?

-Ekr


--e89a8f6469ed25692a04e37bd4d0-- From richard@shockey.us Fri Aug 9 06:15:56 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675EA21F9F74 for ; Fri, 9 Aug 2013 06:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGlCjX-cJwLG for ; Fri, 9 Aug 2013 06:15:50 -0700 (PDT) Received: from oproxy12-pub.mail.unifiedlayer.com (oproxy12-pub.mail.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 3C5EC21F9FD7 for ; Fri, 9 Aug 2013 06:15:44 -0700 (PDT) Received: (qmail 25923 invoked by uid 0); 9 Aug 2013 13:15:18 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.mail.unifiedlayer.com with SMTP; 9 Aug 2013 13:15:18 -0000 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:Date:Subject:In-Reply-To:References:Cc:To:From; bh=BlM6jt0d4bPweLbBxo5orK3iqB3SEgfhi9O4zjuycXU=; b=Uk3OWgwMmUq8tpehSMe64AE8EP0jamc5rec9fgsKqt5dAiMQt9jDTBbQYIZY2PJj3yxipH/6jpqPyRFcU4Zj8ztoFZxbkryANnVAnLdcJ/26JG26wpSiJlF459zmqRQp; Received: from [71.114.100.16] (port=51272 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V7mXF-0006kF-Qd; Fri, 09 Aug 2013 07:15:18 -0600 From: "Richard Shockey" To: "'Eric Rescorla'" , "'Eric Burger'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> In-Reply-To: Date: Fri, 9 Aug 2013 09:15:15 -0400 Message-ID: <00b201ce9502$7daf8090$790e81b0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01CE94E0.F6A114E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAmNFLYoCnpukhgEvNu42AjGYGeoCHZbkzZhTe0Fw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:15:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B3_01CE94E0.F6A114E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, August 09, 2013 12:01 AM To: Eric Burger Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger > wrote: On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan > wrote: > On Aug 5, 2013, at 4:36 PM, Eric Burger > wrote: > I agree we are not looking at a national security private network analysis. However, we are talking about the potential end of any privacy or anonymity for ANY Internet application, more especially Internet multimedia application. > [RS> ] Well I think Deep Packet Inspection tools took care of that issue years ago. > How so? Obviously we could theoretically create some mechanism that took all call information from/to everyone and posted it to wikileaks or > whatever, but I don't think we're that stupid. (nor do I think it would get published by the IETF, nor would anyone use it if we did) > > No one is proposing, for example, that anonymous calls no longer remain anonymous. Nor that one can't make anonymous calls. Actually, we are. We are talking about "official" calling. Otherwise, we would have p2psip and there would not be regulators in the middle. It would not be hard to imaging regulators banning anonymous calling, as the bad guys all use anonymous calling and grandpa still answers the call and hands over his life savings to the nice lady on the phone. I'm not following this argument at all. The regulators could presumably require this now. How does STIR change the situation? [RS> ] A. You are correct. Regulators could require this now, since they have plenary authority of how their portions of the E.164 plan are used and in the case of Germany Caller ID spoofing is not allowed under any circumstances. B. STIR would not change anything. The difference here is what is displayed vs what the network would be able to track and validate. The STIR exercise is about restoring some level of trust in interconnected realtime communications applications that use E.164 naming. -Ekr ------=_NextPart_000_00B3_01CE94E0.F6A114E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Eric Rescorla
Sent: Friday, August 09, 2013 12:01 = AM
To: Eric Burger
Cc: = stir@ietf.org
Subject: Re: [stir] Early Homework (was Re: = Moving from BOF to Charter)

 

 

 

On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger <eburger@standardstrack.com> = wrote:

On Aug 6, = 2013, at 6:50 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com&g= t; wrote:
> On Aug 5, 2013, at 4:36 PM, Eric Burger <eburger@standardstrack.com= > wrote:
> I agree we are not looking at a national security = private network analysis. However, we are talking about the potential = end of any privacy or anonymity for ANY Internet application, more = especially Internet multimedia application.
>

[RS> ]  Well I think Deep Packet Inspection tools took care = of that issue years ago.


> How so? =  Obviously we could theoretically create some mechanism that took = all call information from/to everyone and posted it to wikileaks = or
> whatever, but I don't think we're that stupid. (nor do I = think it would get published by the IETF, nor would anyone use it if we = did)
>
> No one is proposing, for example, that anonymous = calls no longer remain anonymous.  Nor that one can't make = anonymous calls.

Actually, we = are. We are talking about "official" calling. Otherwise, we = would have p2psip and there would not be regulators in the middle. It = would not be hard to imaging regulators banning anonymous calling, as = the bad guys all use anonymous calling and grandpa still answers the = call and hands over his life savings to the nice lady on the = phone.

 

I'm not following this argument at all. The regulators = could presumably

require = this now. How does STIR change the = situation?

 

[RS> ]  A.  You are correct. Regulators could require = this now, since they have plenary authority of how their portions of the = E.164 plan are used and in the case of Germany Caller ID spoofing is not = allowed under any circumstances.  B. STIR would not change = anything.  The difference here is what is displayed vs what the = network would be able to track and validate.  The STIR exercise is = about restoring some level of trust in interconnected realtime = communications applications that use E.164 naming. =

 

-Ekr

 

 

------=_NextPart_000_00B3_01CE94E0.F6A114E0-- From housley@vigilsec.com Fri Aug 9 07:00:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CE821F967C for ; Fri, 9 Aug 2013 07:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2fzl0zOMPtI for ; Fri, 9 Aug 2013 07:00:45 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0EA21F949F for ; Fri, 9 Aug 2013 07:00:45 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9158FF2408B; Fri, 9 Aug 2013 10:01:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id d17-8Yh7ibbc; Fri, 9 Aug 2013 10:00:25 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9D135F24085; Fri, 9 Aug 2013 10:01:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Fri, 9 Aug 2013 10:00:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> To: Brian Rosen X-Mailer: Apple Mail (2.1085) Cc: "lynch@isoc.org" , IETF STIR Mail List , Stephen Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:00:50 -0000 Below is the current charter text. Is it ready for the IESG? Russ > Thanks. >=20 > Is that it? Is everyone okay with the charter language now? Russ = will post a new complete version just to make sure, but can we send this = to the IESG and ask for the work group? >=20 > Brian =3D =3D =3D =3D =3D =3D =3D =3D=20 Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir The STIR working group will specify mechanisms for the validation of source telephone number for an incoming call. Since it has become fairly easy to present an incorrect source telephone number, = a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited = commercial communications), vishing (voicemail hacking, and impersonating banks) = and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or lead = to a return call at premium rates. This working group will define mechanisms that verify the authorization of the calling party to use a particular telephone number. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working = group. To date, however, true validation of the source of SIP calls has not = seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack = of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify a = SIP header-based mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band = mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key and is associated with the one or more telephone numbers. In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a = telephone number without compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band mechanism. However, the in-band and = the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is = to develop a solution for telephone numbers. The working group will coordinate with the Security Area on credential management. The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments. Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. A called party will receive an indication that the source telephone number is unavailable in order to provide anonymity. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to user agents or third parties than a call that does not make use of secure telephone identification mechanisms. Input to working group discussions shall include: - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks [RFC 3325] - Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) [RFC 4474] - Secure Call Origin Identification [draft-cooper-iab-secure-origin-00] - Secure Origin Identification: Problem Statement, Requirements, and Roadmap [draft-peterson-secure-origin-ps-00] - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-jennings-dispatch-rfc4474bis-00] The working group will deliver the following: - A problem statement detailing the deployment environment and situation that motivate work on secure telephone identity - A threat model for the secure telephone identity mechanisms - A privacy analysis of the secure telephone identity mechanisms - A mechanism document describing the SIP end-to-end with telephone number-based identities=20 - A document describing the credentials required to support telephone number identity authentication - A fallback mechanism to allow out-of-band identity establishment during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit threat model for Informational Nov 2013 Submit in-band mechanism for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Apr 2014 Submit Privacy analysis for Informational Jun 2014 Submit out-of-band mechanism for Proposed Standard From ekr@rtfm.com Fri Aug 9 07:30:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5FB21F9957 for ; Fri, 9 Aug 2013 07:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.95 X-Spam-Level: X-Spam-Status: No, score=-102.95 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prj9MMJbJyQR for ; Fri, 9 Aug 2013 07:30:19 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0D28021E8054 for ; Fri, 9 Aug 2013 07:30:01 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id o19so914270qap.20 for ; Fri, 09 Aug 2013 07:30:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TuRbRY/NIB0O1ZaUReADUTbDF9Vd1pNNCMkAoCgIqCs=; b=VugV9GPYWOqn8NODfttYniDZW39llbFrVBZPqDpQEcQm3Geeuq89IgQH3suz5kxLgo D6tJr4RA/cmIZnYq8n3atIefCbgJP94deu8I9hfOKV1NbUtM80sG33clSXGWgKotZPbO JQIqeM0aVaiGsUrmbq8ssu9m1LtT9NOqkzXCJVoTds7TJK+R206kPynFmMDsei0SO9N+ qp30XGooiGBivvKwmBSFM4bebjT6EfiUBl7gRF3t+jWqaAITM+3Ip6RlM5MoHRwSKt4B El4k4Wn8U6aohnFlp1FJPeSvxLQueOfsg4qxid6Ve7tPRgpb5iaR6AIyvUuQp70Xpggs QhVA== X-Gm-Message-State: ALoCoQk7zxWNFVmaiAb4HPmuJIwFL4qKxnR3TtMuMSltf2+ZUyFF8dsm5U/6K/SpMZPg03KeyJWR X-Received: by 10.224.51.12 with SMTP id b12mr11415546qag.53.1376058601333; Fri, 09 Aug 2013 07:30:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Fri, 9 Aug 2013 07:29:21 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> From: Eric Rescorla Date: Fri, 9 Aug 2013 07:29:21 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=047d7bdc78ae1f756604e3849ca4 Cc: "lynch@isoc.org" , IETF STIR Mail List , Stephen Kent , Brian Rosen Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:30:24 -0000 --047d7bdc78ae1f756604e3849ca4 Content-Type: text/plain; charset=ISO-8859-1 This looks basically good to me. Some wordsmithing below. -Ekr On Fri, Aug 9, 2013 at 7:00 AM, Russ Housley wrote: > Below is the current charter text. Is it ready for the IESG? > > Russ > > > Thanks. > > > > Is that it? Is everyone okay with the charter language now? Russ will > post a new complete version just to make sure, but can we send this to the > IESG and ask for the work group? > > > > Brian > > = = = = = = = = > > Name: Secure Telephone Identity Revisited (stir) > Area: RAI > > Chairs: TBD > Area Advisor: Richard Barnes > > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir > > The STIR working group will specify mechanisms for the validation of > source telephone number for an incoming call. Since it > has become fairly easy to present an incorrect source telephone number, a > growing set of problems have emerged over the last decade. As with > email, the claimed source identity of a SIP request is not verified, > permitting unauthorized use of the source identity as part of deceptive > and coercive activities, such as robocalling (bulk unsolicited commercial > communications), vishing (voicemail hacking, and impersonating banks) this may need an e.g., and > swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, use > of an incorrect source telephone number facilitates wire fraud or lead to > maybe "or can lead to" > a return call at premium rates. This working group will define > mechanisms that verify the authorization of the calling party to use a > particular telephone number. > Do the mechanisms verify or "allow verification of..." > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not seen > any appreciable deployment. Several factors contributed to this lack of > success, including: failure of the problem to be seen as critical at the > time; lack of any technical means of producing a proof of authority over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack of > end-to-end SIP session establishment; and inherent operational problems > with a transitive trust model. To make deployment of this solution more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. > > As its priority mechanism work item, the working group will specify a SIP > header-based mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, where the session > is established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone number > representation. The working group will consider choices for protecting > identity information and credentials used, but will likely be based on a > digital signature mechanism that covers a set of information in the SIP > header fields, and verification will employ a credential that contains > the public key and is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a telephone > number without compromising the global delegation scheme. > > In addition to its priority mechanism work item, the working group will > consider session establishment where there are one or more non-SIP hops, > most likely using an out-of-band mechanism. I feel like some words are missing here. Perhaps "providing authorization for session establishment...." "most likely requiring an out-of-band authorization mechanism" However, the in-band and the > out-of-band mechanisms should share as much in common as possible, > especially the credentials. The in-band mechanism must be sent to the > IESG for approval and publication prior to the out-of-band mechanism. > > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is to > develop a solution for telephone numbers. > > The working group will coordinate with the Security Area on credential > management. > > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. > > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. A called > party will receive an indication that the source telephone number is > unavailable in order to provide anonymity. Perhaps: "In order to support anonymity, the output of the WG will provide a mode in which the called party receives an indication..." This working group, to the > extent feasible, will specify privacy-friendly mechanisms that do not > reveal any more information to user agents or third parties than a call > that does not make use of secure telephone identification mechanisms. > > Input to working group discussions shall include: > > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] > > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] > > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] > > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] > > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity > > - A threat model for the secure telephone identity mechanisms > > - A privacy analysis of the secure telephone identity mechanisms > > - A mechanism document describing the SIP end-to-end with telephone > number-based identities > > - A document describing the credentials required to support > telephone number identity authentication > > - A fallback mechanism to allow out-of-band identity establishment > during call setup > > Milestones > > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7bdc78ae1f756604e3849ca4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This looks basically good to me. Some wordsmithing below.<= div>
-Ekr



On Fri, Aug 9, 2013 at 7:00 AM, Russ Housley <= housley@vigilsec.com> wrote:
Below is the current charter text. =A0Is it = ready for the IESG?

Russ

> Thanks.
>
> Is that it? =A0Is everyone okay with the charter language now? =A0Russ= will post a new complete version just to make sure, but can we send this t= o the IESG and ask for the work group?
>
> Brian

=3D =3D =3D =3D =3D =3D =3D =3D

Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: Richard Barnes

Mailing list: stir@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

The STIR working group will specify mechanisms for the validation of
source telephone number for an incoming call. =A0Since it
has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. =A0As with
email, the claimed source identity of a SIP request is not verified,
permitting unauthorized use of the source identity as part of deceptive
and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks)

this may need an e.g.,

and
swatting (impersonating callers to emergency services to stimulate
unwarranted large scale law enforcement deployments). =A0In addition, use of an incorrect source telephone number facilitates wire fraud or lead to

maybe "or can lead to"
=A0
a return call at premium rates. =A0This working group will define
mechanisms that verify the authorization of the calling party to use a
particular telephone number.

Do the mec= hanisms verify or "allow verification of..."

=
=A0
SIP is one of the main VoIP technologies used by parties that want to
present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP
communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. =A0Several factors contributed to this lack of<= br> success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474
with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems
with a transitive trust model. =A0To make deployment of this solution more<= br> likely, consideration must be given to latency, real-time performance,
computational overhead, and administrative overhead for the legitimate
call source and all verifiers.

As its priority mechanism work item, the working group will specify a SIP header-based mechanism to verify the originator of a SIP session is
authorized to use the claimed source telephone number, where the session is established with SIP end to end. =A0This is called an in-band mechanism.=
The mechanism will use a canonical telephone number representation
specified by the working group, including any mappings that might be
needed between the SIP header fields and the canonical telephone number
representation. =A0The working group will consider choices for protecting identity information and credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP
header fields, and verification will employ a credential that contains
the public key and is associated with the one or more telephone numbers. In order to be authoritative, credentials used with this mechanism will
be derived from existing telephone number assignment and delegation
models. =A0That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or
modified) to reflect such delegation. =A0The mechanism must allow a
telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme.

In addition to its priority mechanism work item, the working group will
consider session establishment where there are one or mor= e non-SIP hops,
most l= ikely using an out-of-band mechanism.

I feel like some words are missing here. Perhaps
<= div>"providing authorization for session establishment...."
=
"most likely requiring an out-of-band authorization mechanism&quo= t;


=A0However, th= e in-band and the
out-of-band mechanisms should share as much in common as possible,
especially the credentials. =A0The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism.

Expansion of the authorization mechanism to identities using the
user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

The working group will coordinate with the Security Area on credential
management.

The working group will coordinate with other working groups in the RAI
Area regarding signaling through existing deployments.

Authentication and authorization of identity is closely linked to
privacy, and these security features sometimes come at the cost of
privacy. =A0Anonymous calls are already defined in SIP standards, and this<= br> working group will not propose changes to these standards. =A0A called
party will receive an indication that the source telephone number is<= br> unavailable in order to provide anonymity.

Perhaps:
"In order to support anonymity, the output of the = WG will provide a mode
in which the called party receives an indi= cation..."


=A0This workin= g group, to the
extent feasible, will specify privacy-friendly mechanisms= that do not
reveal any more information to user agents or third parties than a ca= ll
that does not make use of secure telephone identification= mechanisms.

Input to working group discussions shall include:

=A0 - Private Extensions to the Session Initiation Protocol (SIP)
=A0 =A0 for Asserted Identity within Trusted Networks
=A0 =A0 [RFC 3325]

=A0 - Enhancements for Authenticated Identity Management in the
=A0 =A0 Session Initiation Protocol (SIP)
=A0 =A0 [RFC 4474]

=A0 - Secure Call Origin Identification
=A0 =A0 [draft-cooper-iab-secure-origin-00]

=A0 - Secure Origin Identification: Problem Statement, Requirements,
=A0 =A0 and Roadmap
=A0 =A0 [draft-peterson-secure-origin-ps-00]

=A0 - Authenticated Identity Management in the Session Initiation
=A0 =A0 Protocol (SIP)
=A0 =A0 [draft-jennings-dispatch-rfc4474bis-00]

The working group will deliver the following:

=A0 - A problem statement detailing the deployment environment and
=A0 =A0 situation that motivate work on secure telephone identity

=A0 - A threat model for the secure telephone identity mechanisms

=A0 - A privacy analysis of the secure telephone identity mechanisms

=A0 - A mechanism document describing the SIP end-to-end with telephone
=A0 =A0 number-based identities

=A0 - A document describing the credentials required to support
=A0 =A0 telephone number identity authentication

=A0 - A fallback mechanism to allow out-of-band identity establishment
=A0 =A0 during call setup

Milestones

Sep 2013 =A0 Submit problem statement for Informational
Nov 2013 =A0 Submit threat model for Informational
Nov 2013 =A0 Submit in-band mechanism for Proposed Standard
Feb 2014 =A0 Submit credential specification for Proposed Standard
Apr 2014 =A0 Submit Privacy analysis for Informational
Jun 2014 =A0 Submit out-of-band mechanism for Proposed Standard

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--047d7bdc78ae1f756604e3849ca4-- From hadriel.kaplan@oracle.com Fri Aug 9 07:42:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE3321F9962 for ; Fri, 9 Aug 2013 07:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdR170JIWuf8 for ; Fri, 9 Aug 2013 07:42:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED5E21F9994 for ; Fri, 9 Aug 2013 07:42:33 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r79EgWK9020990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 14:42:32 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79EgVXH025099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 14:42:32 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79EgVBN008823; Fri, 9 Aug 2013 14:42:31 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 07:42:30 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 9 Aug 2013 10:42:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <85E501C1-2FDD-4918-910E-D3B5287493F1@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:42:50 -0000 SHIP IT. -hadriel p.s. I too just sent some grammatical nits to Russ directly, but don't = care if they don't get done - just a Type A personality issue. On Aug 9, 2013, at 10:29 AM, Eric Rescorla wrote: > This looks basically good to me. Some wordsmithing below. >=20 > -Ekr >=20 > On Fri, Aug 9, 2013 at 7:00 AM, Russ Housley = wrote: > Below is the current charter text. Is it ready for the IESG? >=20 > Russ >=20 > > Thanks. > > > > Is that it? Is everyone okay with the charter language now? Russ = will post a new complete version just to make sure, but can we send this = to the IESG and ask for the work group? > > > > Brian >=20 > =3D =3D =3D =3D =3D =3D =3D =3D >=20 > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: Richard Barnes >=20 > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir >=20 > The STIR working group will specify mechanisms for the validation of > source telephone number for an incoming call. Since it > has become fairly easy to present an incorrect source telephone = number, a > growing set of problems have emerged over the last decade. As with > email, the claimed source identity of a SIP request is not verified, > permitting unauthorized use of the source identity as part of = deceptive > and coercive activities, such as robocalling (bulk unsolicited = commercial > communications), vishing (voicemail hacking, and impersonating banks) >=20 > this may need an e.g., >=20 > and > swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, = use > of an incorrect source telephone number facilitates wire fraud or lead = to >=20 > maybe "or can lead to" > =20 > a return call at premium rates. This working group will define > mechanisms that verify the authorization of the calling party to use a > particular telephone number. >=20 > Do the mechanisms verify or "allow verification of..." >=20 > =20 > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone = number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working = group. > To date, however, true validation of the source of SIP calls has not = seen > any appreciable deployment. Several factors contributed to this lack = of > success, including: failure of the problem to be seen as critical at = the > time; lack of any technical means of producing a proof of authority = over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack = of > end-to-end SIP session establishment; and inherent operational = problems > with a transitive trust model. To make deployment of this solution = more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. >=20 > As its priority mechanism work item, the working group will specify a = SIP > header-based mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, where the = session > is established with SIP end to end. This is called an in-band = mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone = number > representation. The working group will consider choices for = protecting > identity information and credentials used, but will likely be based on = a > digital signature mechanism that covers a set of information in the = SIP > header fields, and verification will employ a credential that contains > the public key and is associated with the one or more telephone = numbers. > In order to be authoritative, credentials used with this mechanism = will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone = numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a = telephone > number without compromising the global delegation scheme. >=20 > In addition to its priority mechanism work item, the working group = will > consider session establishment where there are one or more non-SIP = hops, > most likely using an out-of-band mechanism. >=20 > I feel like some words are missing here. Perhaps > "providing authorization for session establishment...." > "most likely requiring an out-of-band authorization mechanism" >=20 >=20 > However, the in-band and the > out-of-band mechanisms should share as much in common as possible, > especially the credentials. The in-band mechanism must be sent to the > IESG for approval and publication prior to the out-of-band mechanism. >=20 > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is = to > develop a solution for telephone numbers. >=20 > The working group will coordinate with the Security Area on credential > management. >=20 > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. >=20 > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and = this > working group will not propose changes to these standards. A called > party will receive an indication that the source telephone number is > unavailable in order to provide anonymity. >=20 > Perhaps: > "In order to support anonymity, the output of the WG will provide a = mode > in which the called party receives an indication..." >=20 >=20 > This working group, to the > extent feasible, will specify privacy-friendly mechanisms that do not > reveal any more information to user agents or third parties than a = call > that does not make use of secure telephone identification mechanisms. >=20 > Input to working group discussions shall include: >=20 > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] >=20 > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] >=20 > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] >=20 > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] >=20 > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] >=20 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity >=20 > - A threat model for the secure telephone identity mechanisms >=20 > - A privacy analysis of the secure telephone identity mechanisms >=20 > - A mechanism document describing the SIP end-to-end with telephone > number-based identities >=20 > - A document describing the credentials required to support > telephone number identity authentication >=20 > - A fallback mechanism to allow out-of-band identity establishment > during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From eburger@standardstrack.com Fri Aug 9 08:14:14 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20E11E8255 for ; Fri, 9 Aug 2013 08:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.809 X-Spam-Level: X-Spam-Status: No, score=-101.809 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYj1Ve-GS-AA for ; Fri, 9 Aug 2013 08:14:08 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4421E813C for ; Fri, 9 Aug 2013 08:06:32 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a2A-0003lW-A0 for stir@ietf.org; Thu, 08 Aug 2013 16:54:23 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_A61E2302-0187-4B8F-85BD-E8F5E04192F8"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 8 Aug 2013 19:54:24 -0400 References: <7BBDC0EC-23F0-4DF2-ADB7-A77B6CE8A656@vigilsec.com> <0589FB7B-EC25-461A-ABB8-1AB3A872108C@vigilsec.com> To: IETF STIR Mail List In-Reply-To: X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [stir] Please keep to minute review and charter discussion X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:14:14 -0000 --Apple-Mail=_A61E2302-0187-4B8F-85BD-E8F5E04192F8 Content-Type: multipart/alternative; boundary="Apple-Mail=_3A84ECCF-793C-4BDF-94F6-4236017F1187" --Apple-Mail=_3A84ECCF-793C-4BDF-94F6-4236017F1187 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 And like Hadriel, I am willing to review. On Aug 6, 2013, at 1:37 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Aug 6, 2013 at 10:31 AM, Russ Housley = wrote: > Yes. >=20 > During the BOF, Steve Kent said that he would like to see both a = threat model and a privacy analysis as deliverables early in this = process. What do others think? >=20 > I mostly agree with Steve. >=20 > 1. We should do a threat model as an early deliverable. > 2. We should attempt to do some initial privacy goals as guidelines > early in the process. > 3. Once we have more concrete proposals we should do a privacy > assessment against the goals in #2. >=20 > I am willing to help write all of these. >=20 > -Ekr >=20 > If you support creation of one of these documents, then answer these = two questions. > (1) are you willing to help write one of them? > (2) are you willing to help review one of them? >=20 > Russ >=20 >=20 > On Aug 6, 2013, at 1:29 PM, Hadriel Kaplan wrote: >=20 > > > > Afaik, your current charter questions are: > > > > Q1) What are the population sizes we expect in the long-term, and = what impact does this have on the charter text? > > > > My answer: No impact on charter text. There's a thread on population = sizes, but afaict the answer is "at least medium but possibly BIG". > > > > > > ------------------------- > > > > Q2) The privacy document is fairly straight forward if you only = consider the use of a STIR credential in the in-band and an out-of-band = mechanisms. However, it gets much more complicated if one considers = other potential uses (and abuses) of this credential in other protocol = environments. Do you have any thoughts on this? Do you have proposed = charter text? > > > > My answer: Something along the lines of what Brian said makes sense, = tempered by Henning's response. (how's that for being cryptic? :) > > The proposed charter text you just emailed out a minute ago makes = sense to me. > > > > > > ------------------------- > > > > Q3) The threat document is quite different if it cover an in-band = mechanism or both an in-band and an out-of-band mechanism. Do you have = any thoughts on this? Do you have proposed charter text? > > > > My answer: we do have to enumerate the threats we're concerned with = or not, and having a separate doc makes sense per Steve's referenced BGP = doc. > > > > I propose the following charter text, adding milestone of: "Nov 2013 = Submit A document describing threats to the in-band mechanism for = Informational" > > > > If we can include the out-of-band threats in that, great - and that = should be our stretch objective - but if we can't then we add another = milestone later. The above milestone description does not preclude = going beyond. > > > > ------------------------- > > > > Anything else? > > > > -hadriel > > > > > > > > On Aug 6, 2013, at 12:56 PM, Russ Housley = wrote: > > > >> Once we get chartered, we will need to discuss many of these = topics, but I'd like to focus out energy on getting a working group = chartered. > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > > >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_3A84ECCF-793C-4BDF-94F6-4236017F1187 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 And like Hadriel, I am willing to review.

On Aug 6, 2013, at 1:37 PM, Eric Rescorla <ekr@rtfm.com> wrote:




On Tue, Aug 6, 2013 at 10:31 AM, Russ Housley <housley@vigilsec.com> wrote:
Yes.

During the BOF, Steve Kent said that he would like to see both a threat model and a privacy analysis as deliverables early in this process.  What do others think?

I mostly agree with Steve.

1. We should do a threat model as an early deliverable.
2. We should attempt to do some initial privacy goals as guidelines
early in the process.
3. Once we have more concrete proposals we should do a privacy
assessment against the goals in #2.

I am willing to help write all of these.

-Ekr

If you support creation of one of these documents, then answer these two questions.
(1) are you willing to help write one of them?
(2) are you willing to help review one of them?

Russ


On Aug 6, 2013, at 1:29 PM, Hadriel Kaplan wrote:

>
> Afaik, your current charter questions are:
>
> Q1) What are the population sizes we expect in the long-term, and what impact does this have on the charter text?
>
> My answer: No impact on charter text. There's a thread on population sizes, but afaict the answer is "at least medium but possibly BIG".
>
>
> -------------------------
>
> Q2) The privacy document is fairly straight forward if you only consider the use of a STIR credential in the in-band and an out-of-band mechanisms.  However, it gets much more complicated if one considers other potential uses (and abuses) of this credential in other protocol environments.  Do you have any thoughts on this?  Do you have proposed charter text?
>
> My answer: Something along the lines of what Brian said makes sense, tempered by Henning's response. (how's that for being cryptic? :)
> The proposed charter text you just emailed out a minute ago makes sense to me.
>
>
> -------------------------
>
> Q3) The threat document is quite different if it cover an in-band mechanism or both an in-band and an out-of-band mechanism.  Do you have any thoughts on this?  Do you have proposed charter text?
>
> My answer: we do have to enumerate the threats we're concerned with or not, and having a separate doc makes sense per Steve's referenced BGP doc.
>
> I propose the following charter text, adding milestone of: "Nov 2013 Submit A document describing threats to the in-band mechanism for Informational"
>
> If we can include the out-of-band threats in that, great - and that should be our stretch objective - but if we can't then we add another milestone later.  The above milestone description does not preclude going beyond.
>
> -------------------------
>
> Anything else?
>
> -hadriel
>
>
>
> On Aug 6, 2013, at 12:56 PM, Russ Housley <housley@vigilsec.com> wrote:
>
>> Once we get chartered, we will need to discuss many of these topics, but I'd like to focus out energy on getting a working group chartered.
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--Apple-Mail=_3A84ECCF-793C-4BDF-94F6-4236017F1187-- --Apple-Mail=_A61E2302-0187-4B8F-85BD-E8F5E04192F8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1NDI1WjAjBgkqhkiG9w0BCQQxFgQU +Pd8+Wypv9JblmuQb+3e37+1mCYwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEATuZ/tP1hGsjh5V0c+JDCaBVih2L4evuUgYMnL4lR3mqZoaZxyHVV qsitdJ8HeFYorlPBmo9u1JrFrocp2/f2qaUbP/H38MAbaOqCXqTQWv0kTmavUMOWfHun8k+VOvNw jZgxdiMz5IdYslAO3QstmKzmouXAHnDFVqML85xp9KF03pcZrLfj31LWtsNLcJkyBsIyn1U0QlS4 P8mKbnuPnQ5SwhB07A0MKeUNZeNUBTR4p4weHfIWxtzg+h1C8sG+UhbgC0od7OYl2Cv/VK5WVlJN uLajJif93kgFGs+B0S7RpwLEOBOk5dMleTz8dn0vW2eaMmZKL/Rbo2NK/ROeWgAAAAAAAA== --Apple-Mail=_A61E2302-0187-4B8F-85BD-E8F5E04192F8-- From eburger@standardstrack.com Fri Aug 9 08:14:17 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C5A11E825A for ; Fri, 9 Aug 2013 08:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.037 X-Spam-Level: X-Spam-Status: No, score=-101.037 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-gb--jTh+zA for ; Fri, 9 Aug 2013 08:14:12 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 41EAD21E80A8 for ; Fri, 9 Aug 2013 08:06:34 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a2R-0003lW-Dy; Thu, 08 Aug 2013 16:54:40 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_692C52A0-6239-4EA9-9CEA-07C9AB669851"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric Burger In-Reply-To: <00b801ce91e7$08774470$1965cd50$@shockey.us> Date: Thu, 8 Aug 2013 19:54:43 -0400 Message-Id: <17C6D9DB-B476-44E5-94DA-CC336C62A23B@standardstrack.com> References: <00b801ce91e7$08774470$1965cd50$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Cc: stir@ietf.org Subject: Re: [stir] FYI ... the UK Ofcom view of the problem statement. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:14:17 -0000 --Apple-Mail=_692C52A0-6239-4EA9-9CEA-07C9AB669851 Content-Type: multipart/alternative; boundary="Apple-Mail=_8567A06D-AE82-4617-AD96-0FBEFA034A85" --Apple-Mail=_8567A06D-AE82-4617-AD96-0FBEFA034A85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This tidbit is interesting: In addition, BT has agreed to display full telephone numbers of inbound = calls from abroad as routine (currently BT customers with phones with = caller display will only see =93INTL=94). This requires technical = changes in BT=92s network that will take some time to implement but = customers should start to see these changes towards the end of this = year. All customers should have this facility by autumn 2014. As some said in the BOF, international solutions will be important = outside North America. On Aug 5, 2013, at 10:21 AM, Richard Shockey wrote: > =20 > = http://stakeholders.ofcom.org.uk/consultations/silent-calls/joint-action-p= lan/ > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > skype-linkedin-facebook: rshockey101 > http//www.sipforum.org >=20 > "Money is the answer, what is the question?" tm >=20 > =20 >=20 > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_8567A06D-AE82-4617-AD96-0FBEFA034A85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 This = tidbit is interesting:
richard@shockey.us> = wrote:

 

http://stakeholders.ofcom.org.uk/consultations/silent-calls/= joint-action-plan/

Richard Shockey
Shockey = Consulting
Chairman of the Board of Directors SIP Forum
PSTN = Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype-= linkedin-facebook: rshockey101
http//www.sipforum.org

"Money is the answer, what is the = question?" tm

 

 

_____________________= __________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_8567A06D-AE82-4617-AD96-0FBEFA034A85-- --Apple-Mail=_692C52A0-6239-4EA9-9CEA-07C9AB669851 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1NDQ0WjAjBgkqhkiG9w0BCQQxFgQU ca3LgWG+5A8c73w4IuhANIJVyz4wgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAAgpEvsEpBbvQ9kt4K0pHXPHW5V2Z/Q83BSOBmgrpUsEY3Rbswyqt 9EgUHxJblg7srsfEpVd2ZdoXXpvDgrw0DSRGHcIE6K+0PU19oWdUggPeDkYHFqlvUc1n6gVcfvcw BaRUZudC9LIa/MRWEkUoI8kGCuBJKRwAWmgm7o68lu6Th3Pf24OWEqqGa5hMNp/jH6an/LbEeHG2 MtQ3SMNZ6AtlKkBXrALbYFZUXnokN8e1xiLvEj+petgjnNtn0OJDHTBYywVGRHTu8nSeMhHHvNwF N0oUehdNuYTX8mLsGrkAJ/iJIkSwYKw+DN3jrpJcX/oEnsUczztwt9cczam7awAAAAAAAA== --Apple-Mail=_692C52A0-6239-4EA9-9CEA-07C9AB669851-- From eburger@standardstrack.com Fri Aug 9 08:14:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6BF11E825B for ; Fri, 9 Aug 2013 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.917 X-Spam-Level: X-Spam-Status: No, score=-101.917 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWwBLC5UoetI for ; Fri, 9 Aug 2013 08:14:14 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9645421E8141 for ; Fri, 9 Aug 2013 08:06:34 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a2M-0003lW-QA for stir@ietf.org; Thu, 08 Aug 2013 16:54:35 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_36F220A3-173E-4DA9-A308-E2E12C4905E2"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <96DE5144-389E-4450-B3D7-C723957DC06C@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 8 Aug 2013 19:54:38 -0400 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <5BC9B1BA-1862-4505-B6A3-4992E9133EBD@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC23D2D@EX2K10MB1.corp.yaanatech.com> To: stir@ietf.org In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC23D2D@EX2K10MB1.corp.yaanatech.com> X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [stir] Population Size X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:14:19 -0000 --Apple-Mail=_36F220A3-173E-4DA9-A308-E2E12C4905E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And if it does not need to operate at Internet scale, why are we working = on it? On Aug 5, 2013, at 8:28 PM, Michael Hammer = wrote: > I vote for a gazillion. >=20 > We could just say it needs to operate at Internet scale and move on. >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Hadriel Kaplan > Sent: Monday, August 05, 2013 7:26 PM > To: Russ Housley > Cc: IETF STIR Mail List > Subject: Re: [stir] Population Size >=20 >=20 > On Aug 5, 2013, at 3:59 PM, Russ Housley wrote: >=20 >> Steve Kent raised a question on the list about the population size. = I > think we need to consider this question in the long-term. That is = after > both the in-band and out-of-band mechanisms have been developed and > deployed. >>=20 >> Steve said: =20 >>=20 >>> I also think we need to have a discussion about the size of the=20 >>> population of calling parties who will have credentials, and the = size=20 >>> of the verifiers in the system. This seemed to be the source of some=20= >>> disagreement during the BoF, and some proposals that might work well=20= >>> for small values of either (or both) of these parameters might not = work > well for very large values of these parameters. >>=20 >> So, I'd like to hear what people think, and what impact this has on = the > charter text. >=20 > Why would this have impact on the charter text? >=20 > Brian gave some numbers before on the list: >> There are several billion telephone numbers. I think most experts = believe > there are more assigned numbers than people. =20 >> There are 300-odd country codes >> There are a few tens of thousands of service providers. If=20 >> enterprises get some form of credential, there are potentially high=20= >> tens of millions >=20 >=20 > The likely target sizes, imo, if we think this will be world-wide: > There are ~250 numbering authorities (cert CAs or PKI roots or = whatever) > Signers are only service providers and big Enterprises =3D ~50,000 max = signing > organizations Verifiers are only service providers and big Enterprises = =3D > ~50,000 max verifier organizations >=20 > If you're asking about number of signing/verifying physical *systems*, = it's > way more than 50k. >=20 > If the doctor's office scenario occurs and is done by the phone = itself, > there still aren't very many of those in practice, so it likely = doesn't > matter much. >=20 > It's possible that LTE mobile phones might do signing someday, in = certain > roaming cases. It's possible they might do verifying as well. If so, = that > would balloon things fast. I don't think that's likely to happen = though. >=20 > It's possible that one or more countries might impose requirements = that > Enterprises, or even LTE mobile phones, do both the signing and = verifying - > or at least that they be allowed to. I can imagine a few countries in > Europe doing that, for example. If that happens, that would balloon = things > to many millions, of course. >=20 > The hard part with these things is we don't actually know the answer. = It's > not hard to imagine new features one could enable were such a PKI = available, > and if that happens, all bets are off. Some PSTN features people = thought > would be super-popular fizzled out (e.g., ISDN video), while other = things > that people thought would be minor became mega-hits instead (e.g., SMS = and > number porting). >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_36F220A3-173E-4DA9-A308-E2E12C4905E2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1NDM5WjAjBgkqhkiG9w0BCQQxFgQU AAicme3hUSQHHPTr75rjTjLz61MwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAWKuqiYzNxaNc8QghjeMMfTXjN3Ipbkh5aA62iyynqVTrhRDMsmEO Q5JEWv0BEEZDUNmdisuoehyREBw/n455Nsz5wFKK/88+tXA8V9Evf86ZMKiDGa4yeiAmIIG/lWSp O4huBLxrtzf/JdGE09wZYpR4OsplnTHWZhG+BesXh2PiqD3XO0ZANzCTISKXL2sl7DjYZIQuvodZ QNVDn8ZAe+5qsayYyOrFOVdUikzfLtED3aF7as8sIyMlaIFv90Ks4fMRcjdYqOpZBVfOch0m0KKv jsuWb7Aoc+H/K5NtsR53N7kb0BFO97BMwo+aCq88HjC8C9njubQYCCke3YqnpwAAAAAAAA== --Apple-Mail=_36F220A3-173E-4DA9-A308-E2E12C4905E2-- From eburger@standardstrack.com Fri Aug 9 08:14:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A61111E8262 for ; Fri, 9 Aug 2013 08:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.857 X-Spam-Level: X-Spam-Status: No, score=-101.857 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vcEA8Sq95l9 for ; Fri, 9 Aug 2013 08:14:17 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id C5EB021E8142 for ; Fri, 9 Aug 2013 08:06:34 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a2D-0003lW-9D; Thu, 08 Aug 2013 16:54:26 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_34A08F06-2F94-4EA0-B66B-84EF031702DC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric Burger In-Reply-To: <520100AC.7040601@alum.mit.edu> Date: Thu, 8 Aug 2013 19:54:29 -0400 Message-Id: <057B0D85-E27C-4497-A0D6-CE209D909440@standardstrack.com> References: <1E587684-70A3-4782-AD7E-98169F3BB0B1@standardstrack.com> <520100AC.7040601@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Cc: stir@ietf.org Subject: Re: [stir] 15ms??? Where the heck did that come from? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:14:24 -0000 --Apple-Mail=_34A08F06-2F94-4EA0-B66B-84EF031702DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And out of band can be parallel. However, here's an interesting thought: = the client is most likely going to 183 the call until it gets the = authenticated response. That means service providers are going to be = holding the bag for Xms extra for, if STIR is successful, every call. = That's hundreds of millions of minutes per month. Good thing we are not = talking TDM where DS0's would be allocated and blocked! On Aug 6, 2013, at 9:57 AM, Paul Kyzivat wrote: > The ideal is that this be done in *parallel*, not *series* with other = processing, so that most of the cost doesn't normally add to the delay. >=20 > Thanks, > Paul >=20 > On 8/6/13 1:38 PM, Hadriel Kaplan wrote: >>=20 >> Agreed - the budget is not as low as 15ms, but nowhere near as high = as 4 seconds. It's actually quite hard to come up with a hard limit = though, as a general requirement for STIR for all scenarios. Generally = I just think of it as: "as low as we can possibly make it". >>=20 >> Some people have been talking about it from the perspective of = acceptable post-dial-delay (PDD), but I think that's the wrong way to = think about it - because STIR is adding additional time to whatever is = already deployed today. So the real question is how much *additional* = time do we think STIR can introduce, without being a barrier to = adoption. That's why for me the topic boils down to "make it = super-frigging' fast". >>=20 >> As an equipment vendor, for example, my employer gets requirements = for SIP message processing in the order of single-digit milliseconds if = there's no external DB query. Even when we query external databases, = we're sometimes required to stop waiting for a DB answer after only tens = of milliseconds (or less than 100ms), and forward the call on = regardless. This may be because some wholesale carrier SLAs are = measured on post-dial-delay; or it may just be because so many systems = are involved in call processing, and the cumulative delay would become = so untenable, that the carriers decide to require a consistent common = max value for all systems. I don't know for sure. Either way, carriers = are very sensitive to call delays. >>=20 >> [As an aside for those who care: according to ITU E.721, the mean = delay budget for end-to-end PDD is 3 seconds for local calls, 5 seconds = for national long-distance, and 8 seconds for international. But that = spec is really conservative and is based on phone-to-phone time. For = the SS7 network, a different spec (E.723) gives the end-to-end PDD = across the SS7 system as 0.9 seconds for local calls, 2.3 seconds for = long-distance, and 4 seconds for international. Mobile phones/networks = have a different set of values, I believe. But again, looking at these = numbers provides a false sense of time budget for STIR.] >>=20 >> -hadriel >>=20 >>=20 >> On Aug 5, 2013, at 4:37 PM, Eric Burger = wrote: >>=20 >>> In the STIR BOF I mentioned that the time budget for *additional* = processing in the PSTN world would be on the order of 15ms. I need to = put a LOT of context around that statement. >>>=20 >>> Twenty years ago (NOT TODAY), routing special PSTN calls, like free = phone or virtual networks, had a very tight time budget. There were both = government performance mandates and consumer drivers that ensured = carriers routed calls quickly. The big driver is callers might wait up = to 2500ms before they would abandon the call. At my company, the saying = we had was we never want one of our customers to say, "Why did I ever = switch from brand A?" as they hung up the phone and redialed. >>>=20 >>> Given the latencies of local switches routing to long distance = switches, the latencies of breaking out call signaling to make a dozen = or so data base lookups, and returning the result so the call could be = routed to its destination, our total processing budget was 70ms. That = was the days of 30ms access time disks, so you can see the problem. >>>=20 >>> So, on the one hand, in an IP environment we have a lot more time = than 15ms to do authentication steps, as we can do that work in parallel = to other routing logic. We are not restricted to adding on the exchanges = and algorithms in sequence to other routing processing. >>>=20 >>> On the other hand, the statement that the budget is 10000ms is = beyond reality. Even in a World of Warcraft chat room, no one is going = to wait 10 seconds in the hope a connection request is successful. = Granted, mobile phones and early VoIP systems have trained users to have = a little more patience than 2500ms. However, to expect a user, in a PSTN = emulation environment, to hang on for more than 4000ms or 5000ms is = wishful thinking._______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_34A08F06-2F94-4EA0-B66B-84EF031702DC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1NDMwWjAjBgkqhkiG9w0BCQQxFgQU 4yD6u5V4ZaAGGy7wxLfU9ZDFfxYwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAi0UQtpU9CTms+YiLgNQyERUiSsYYZ+Ku4SlQHJ3lG7INFq5wM0uy ecREFmB7z9A1mplVOfCZJzcJcrLjfeTcgC2M37l2HiPZkQtmcK10RjJR5JjBM2n4WA8Km/3GqysZ LoXkHcmp9njqApxtcZrGWvARSdSsdA8KvhklqIJ+S6rWmhan+61V6u6gLnl7Qy5fo97EVBOJcoa0 ciJ0G/ZQa0LT1M2YuaLS9ClruTLJt3SYZOdm/NTUDnHdmY6uyTK6LCvn48RXy86WHe/6wSjYTGKc 4QPcckSpgCDekNYel8QW0XhyC4i/zRL58ftx6QQcd/Qg21tWzNz1qlOx7WYpqAAAAAAAAA== --Apple-Mail=_34A08F06-2F94-4EA0-B66B-84EF031702DC-- From eburger@standardstrack.com Fri Aug 9 08:14:29 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0743311E8260 for ; Fri, 9 Aug 2013 08:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuF2g7CmANnH for ; Fri, 9 Aug 2013 08:14:19 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 27B1F21E80BA for ; Fri, 9 Aug 2013 08:06:35 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a29-0003lW-6z; Thu, 08 Aug 2013 16:54:21 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_EAC5CFB4-CB8C-49F3-82DD-202255B55015"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric Burger In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC24127@EX2K10MB1.corp.yaanatech.com> Date: Thu, 8 Aug 2013 19:54:20 -0400 Message-Id: <245953A4-CF9C-4DD4-878C-11CE49F5FA07@standardstrack.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2401A@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC24127@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Cc: stir@ietf.org Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:14:29 -0000 --Apple-Mail=_EAC5CFB4-CB8C-49F3-82DD-202255B55015 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What should go in the charter? On Aug 6, 2013, at 11:26 AM, Michael Hammer = wrote: > All of them. >=20 >=20 > -----Original Message----- > From: Dan York [mailto:york@isoc.org]=20 > Sent: Tuesday, August 06, 2013 11:21 AM > To: Michael Hammer; hadriel.kaplan@oracle.com; = eburger@standardstrack.com > Cc: stir@ietf.org > Subject: Re: [stir] Legitimate uses of third party Caller ID = authorization / > spoofing for outbound calling - Re: What are we trying to do, and = where do > we want to end up? >=20 > Mike, >=20 >=20 > On 8/6/13 10:48 AM, "Michael Hammer" = wrote: >=20 >> Yes, but that doesn't mean you have to lie about the true originator = of=20 >> the call separate from what to display on caller ID or what to = provide=20 >> as a call-back number. >=20 > Sure... but the reality is that if we have a field providing origin > identification it will probably be used for both. >=20 >=20 >> Many of the problems arise from conflating multiple purposes into the=20= >> same field. >=20 > Perhaps we need to be more clear on who is the consumer of the = field(s) we > are creating: >=20 > - Are we trying to help consumers know who is calling them? > - Are we trying to help carriers / service providers be able to track = and > potentially block calls? > - Are we trying to do both? >=20 > Dan >=20 --Apple-Mail=_EAC5CFB4-CB8C-49F3-82DD-202255B55015 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1NDIwWjAjBgkqhkiG9w0BCQQxFgQU /zC9Ww4EvQyl42DfZVvWQ8FJgBkwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAUoGVsaG/OqhURIwrCvp0lwvDzDotPuliTIXGWwyrMcGlal1md6MF UYW5F39EOZNkVYsjYFPS7LFslCJHMTSPfQnMZI1QVQ7wRuaFW6/Du+Jj9IbIWm41xue7UvyJdDGy wPpzrJsyIi+KuWcYMM47BYo3IZp8nYd7Il31eLO3TngtrueJ9PB+NfjxQTfwsNFN0CsdnnklS+ID xaGC0Pz//2owkdirPnffBPZIF8VRIR07RPARMGGrEqgrxqpLjoX2nPtWilf7t6Cc5Rk9rmwnFVdV fNuCTwpsLk9FWx3TPB3fSIQ2wMjPhvhwvNSUMbZjaSgHMWhp7nEgwhYxpyhGMQAAAAAAAA== --Apple-Mail=_EAC5CFB4-CB8C-49F3-82DD-202255B55015-- From eburger@standardstrack.com Fri Aug 9 08:14:30 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9699111E8267 for ; Fri, 9 Aug 2013 08:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVyK80hur-1A for ; Fri, 9 Aug 2013 08:14:24 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEC121E8144 for ; Fri, 9 Aug 2013 08:06:35 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:52776 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7a28-0003lW-Fh for stir@ietf.org; Thu, 08 Aug 2013 16:54:20 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_B8E3B716-C454-4B2D-A3EE-FE78780573EE"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 8 Aug 2013 19:54:16 -0400 References: <4E3AFB6B-692D-46A7-A374-74F14E2AE1C5@vigilsec.com> To: IETF STIR Mail List In-Reply-To: <4E3AFB6B-692D-46A7-A374-74F14E2AE1C5@vigilsec.com> X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [stir] Next Draft of the Charter -- 6-Aug-2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:14:30 -0000 --Apple-Mail=_B8E3B716-C454-4B2D-A3EE-FE78780573EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I know, we are doing the threat model first and then the mechanism. And = yes, that work will be in parallel. However, is it realistic to say that = by the time one has consensus on the threat model the work on in-band = will be fully baked and unchanged from the threat analysis? On the other hand, specifying November 2013 as a delivery date for = in-band could be an easy $100 for me (anyone want to take that bet?). On Aug 6, 2013, at 3:46 PM, Russ Housley wrote: > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard --Apple-Mail=_B8E3B716-C454-4B2D-A3EE-FE78780573EE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA4MjM1NDE3WjAjBgkqhkiG9w0BCQQxFgQU Q+kUf4puXSEVBJOu1bmJdPSQWAAwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAcQJVbljN/ZOOQHawNrstyASSo3y1LB7Fe+XWhadCs9r9+3qDaAJA /T0PW+JBPUjOZxwkqDMadn3EOFMgGzbWRS8LkFYYZwFv1ILeBdabYIAuY3DMgISG+mlLQwIbUA3T vE9vwcB3L0Z9+xoCzzOTqD5qa33gtHU5LKO3eKcMvqOXBVXR84sEoqxd0XPvDxW5k8+AJX3Y27P2 /bHJwbdbfnBaSuEkYyCyTM8s0tJnrUVUAeBBUlxZ4oSncc6BakSiwO+67wfbKO/jhHuUSLKlkgnE hwtHMJZFkucDpeBgvVd52jUIiweyE/5x/XZ5SF2gEflxRkgRhExTzIJqDIDwRAAAAAAAAA== --Apple-Mail=_B8E3B716-C454-4B2D-A3EE-FE78780573EE-- From jgunn6@csc.com Fri Aug 9 08:31:05 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422BC11E81CF; Fri, 9 Aug 2013 08:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu5LyfJKNVll; Fri, 9 Aug 2013 08:31:00 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 64A6C21F9FE9; Fri, 9 Aug 2013 08:21:34 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-85.messagelabs.com!1376061691!21630105!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16739 invoked from network); 9 Aug 2013 15:21:31 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-2.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Aug 2013 15:21:31 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (8.13.8/8.13.8) with ESMTP id r79FISio029157; Fri, 9 Aug 2013 11:18:28 -0400 In-Reply-To: References: <7BBDC0EC-23F0-4DF2-ADB7-A77B6CE8A656@vigilsec.com> <0589FB7B-EC25-461A-ABB8-1AB3A872108C@vigilsec.com> To: Eric Burger MIME-Version: 1.0 X-KeepSent: C47A9BDC:D6A09E3B-85257BC2:0054539A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Fri, 9 Aug 2013 11:21:30 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 08/09/2013 11:14:56 AM, Serialize complete at 08/09/2013 11:14:56 AM Content-Type: multipart/alternative; boundary="=_alternative 00545E1D85257BC2_=" Cc: IETF STIR Mail List , stir-bounces@ietf.org Subject: Re: [stir] Please keep to minute review and charter discussion X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:31:05 -0000 This is a multipart message in MIME format. --=_alternative 00545E1D85257BC2_= Content-Type: text/plain; charset="US-ASCII" I am also willing to review. Janet > And like Hadriel, I am willing to review. > > On Aug 6, 2013, at 1:37 PM, Eric Rescorla wrote: > > > On Tue, Aug 6, 2013 at 10:31 AM, Russ Housley wrote: > Yes. > > During the BOF, Steve Kent said that he would like to see both a > threat model and a privacy analysis as deliverables early in this > process. What do others think? > > I mostly agree with Steve. > > 1. We should do a threat model as an early deliverable. > 2. We should attempt to do some initial privacy goals as guidelines > early in the process. > 3. Once we have more concrete proposals we should do a privacy > assessment against the goals in #2. > > I am willing to help write all of these. > > -Ekr > > If you support creation of one of these documents, then answer these > two questions. > (1) are you willing to help write one of them? > (2) are you willing to help review one of them? > > Russ > > > On Aug 6, 2013, at 1:29 PM, Hadriel Kaplan wrote: > > > > > Afaik, your current charter questions are: > > > > Q1) What are the population sizes we expect in the long-term, and > what impact does this have on the charter text? > > > > My answer: No impact on charter text. There's a thread on > population sizes, but afaict the answer is "at least medium but possibly BIG". > > > > > > ------------------------- > > > > Q2) The privacy document is fairly straight forward if you only > consider the use of a STIR credential in the in-band and an out-of- > band mechanisms. However, it gets much more complicated if one > considers other potential uses (and abuses) of this credential in > other protocol environments. Do you have any thoughts on this? Do > you have proposed charter text? > > > > My answer: Something along the lines of what Brian said makes > sense, tempered by Henning's response. (how's that for being cryptic? :) > > The proposed charter text you just emailed out a minute ago makes > sense to me. > > > > > > ------------------------- > > > > Q3) The threat document is quite different if it cover an in-band > mechanism or both an in-band and an out-of-band mechanism. Do you > have any thoughts on this? Do you have proposed charter text? > > > > My answer: we do have to enumerate the threats we're concerned > with or not, and having a separate doc makes sense per Steve's > referenced BGP doc. > > > > I propose the following charter text, adding milestone of: "Nov > 2013 Submit A document describing threats to the in-band mechanism > for Informational" > > > > If we can include the out-of-band threats in that, great - and > that should be our stretch objective - but if we can't then we add > another milestone later. The above milestone description does not > preclude going beyond. > > > > ------------------------- > > > > Anything else? > > > > -hadriel > > > > > > > > On Aug 6, 2013, at 12:56 PM, Russ Housley wrote: > > > >> Once we get chartered, we will need to discuss many of these > topics, but I'd like to focus out energy on getting a working group chartered. > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > [attachment "smime.p7s" deleted by Janet P Gunn/USA/CSC] > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --=_alternative 00545E1D85257BC2_= Content-Type: text/html; charset="US-ASCII"

I am also willing to review.

Janet

> And like Hadriel, I am willing to review.
>
> On Aug 6, 2013, at 1:37 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>

> On Tue, Aug 6, 2013 at 10:31 AM, Russ Housley <housley@vigilsec.com> wrote:
> Yes.
>
> During the BOF, Steve Kent said that he would like to see both a
> threat model and a privacy analysis as deliverables early in this
> process.  What do others think?
>
> I mostly agree with Steve.
>
> 1. We should do a threat model as an early deliverable.
> 2. We should attempt to do some initial privacy goals as guidelines
> early in the process.
> 3. Once we have more concrete proposals we should do a privacy
> assessment against the goals in #2.
>
> I am willing to help write all of these.
>
> -Ekr
>
> If you support creation of one of these documents, then answer these
> two questions.
> (1) are you willing to help write one of them?
> (2) are you willing to help review one of them?
>
> Russ
>
>
> On Aug 6, 2013, at 1:29 PM, Hadriel Kaplan wrote:
>
> >
> > Afaik, your current charter questions are:
> >
> > Q1) What are the population sizes we expect in the long-term, and
> what impact does this have on the charter text?
> >
> > My answer: No impact on charter text. There's a thread on
> population sizes, but afaict the answer is "at least medium but possibly BIG".
> >
> >
> > -------------------------
> >
> > Q2) The privacy document is fairly straight forward if you only
> consider the use of a STIR credential in the in-band and an out-of-
> band mechanisms.  However, it gets much more complicated if one
> considers other potential uses (and abuses) of this credential in
> other protocol environments.  Do you have any thoughts on this?  Do
> you have proposed charter text?
> >
> > My answer: Something along the lines of what Brian said makes
> sense, tempered by Henning's response. (how's that for being cryptic? :)
> > The proposed charter text you just emailed out a minute ago makes
> sense to me.
> >
> >
> > -------------------------
> >
> > Q3) The threat document is quite different if it cover an in-band
> mechanism or both an in-band and an out-of-band mechanism.  Do you
> have any thoughts on this?  Do you have proposed charter text?
> >
> > My answer: we do have to enumerate the threats we're concerned
> with or not, and having a separate doc makes sense per Steve's
> referenced BGP doc.
> >
> > I propose the following charter text, adding milestone of: "Nov
> 2013 Submit A document describing threats to the in-band mechanism
> for Informational"
> >
> > If we can include the out-of-band threats in that, great - and
> that should be our stretch objective - but if we can't then we add
> another milestone later.  The above milestone description does not
> preclude going beyond.
> >
> > -------------------------
> >
> > Anything else?
> >
> > -hadriel
> >
> >
> >
> > On Aug 6, 2013, at 12:56 PM, Russ Housley <housley@vigilsec.com> wrote:
> >
> >> Once we get chartered, we will need to discuss many of these
> topics, but I'd like to focus out energy on getting a working group chartered.
> >> _______________________________________________
> >> stir mailing list
> >> stir@ietf.org
> >> https://www.ietf.org/mailman/listinfo/stir
> >
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
> [attachment "smime.p7s" deleted by Janet P Gunn/USA/CSC]
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
 --=_alternative 00545E1D85257BC2_=-- From richard@shockey.us Fri Aug 9 08:51:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B3E21F9CAF for ; Fri, 9 Aug 2013 08:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.108 X-Spam-Level: X-Spam-Status: No, score=-102.108 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa3lKe+x7VSI for ; Fri, 9 Aug 2013 08:51:41 -0700 (PDT) Received: from oproxy14-pub.mail.unifiedlayer.com (oproxy14-pub.mail.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 7FD0921F9CC7 for ; Fri, 9 Aug 2013 08:45:01 -0700 (PDT) Received: (qmail 15607 invoked by uid 0); 9 Aug 2013 15:45:00 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 9 Aug 2013 15:45:00 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=HdqUjOyLJkJJy7j+5Dnu0zJWMrAT4UY62s6xlxsAmMo=; b=DOOxrBYZ9CMRHjSFYM2fFfRBgK7hPwM3Tc1P3v+ytG04n7byuETlkyD1e4sGgMuH2qH1WdXYx4OdPpuUR3bWtJRfOHRAkHUs4EoIgybjrlCfY1vh+baII5rdMDyPv7jm; Received: from [71.114.100.16] (port=53972 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V7os6-0001Og-9J; Fri, 09 Aug 2013 09:44:59 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Russ Housley'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> <85E501C1-2FDD-4918-910E-D3B5287493F1@oracle.com> In-Reply-To: <85E501C1-2FDD-4918-910E-D3B5287493F1@oracle.com> Date: Fri, 9 Aug 2013 11:44:55 -0400 Message-ID: <010701ce9517$667bd120$33737360$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQDqwCnHAPUadagCJzGJKQLA787gAkC4ppwCLkhnsAIKBSk5Ac73RZYCFn9vbZgqhuPg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: 'IETF STIR Mail List' Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:51:50 -0000 +1 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, August 09, 2013 10:42 AM To: Russ Housley Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter SHIP IT. -hadriel p.s. I too just sent some grammatical nits to Russ directly, but don't care if they don't get done - just a Type A personality issue. On Aug 9, 2013, at 10:29 AM, Eric Rescorla wrote: > This looks basically good to me. Some wordsmithing below. > > -Ekr > > On Fri, Aug 9, 2013 at 7:00 AM, Russ Housley wrote: > Below is the current charter text. Is it ready for the IESG? > > Russ > > > Thanks. > > > > Is that it? Is everyone okay with the charter language now? Russ will post a new complete version just to make sure, but can we send this to the IESG and ask for the work group? > > > > Brian > > = = = = = = = = > > Name: Secure Telephone Identity Revisited (stir) > Area: RAI > > Chairs: TBD > Area Advisor: Richard Barnes > > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir > > The STIR working group will specify mechanisms for the validation of > source telephone number for an incoming call. Since it has become > fairly easy to present an incorrect source telephone number, a growing > set of problems have emerged over the last decade. As with email, the > claimed source identity of a SIP request is not verified, permitting > unauthorized use of the source identity as part of deceptive and > coercive activities, such as robocalling (bulk unsolicited commercial > communications), vishing (voicemail hacking, and impersonating banks) > > this may need an e.g., > > and > swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, > use of an incorrect source telephone number facilitates wire fraud or > lead to > > maybe "or can lead to" > > a return call at premium rates. This working group will define > mechanisms that verify the authorization of the calling party to use a > particular telephone number. > > Do the mechanisms verify or "allow verification of..." > > > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not > seen any appreciable deployment. Several factors contributed to this > lack of success, including: failure of the problem to be seen as > critical at the time; lack of any technical means of producing a proof > of authority over telephone numbers; misalignment of the mechanisms > proposed by RFC 4474 with the complex deployment environment that has > emerged for SIP; lack of end-to-end SIP session establishment; and > inherent operational problems with a transitive trust model. To make > deployment of this solution more likely, consideration must be given > to latency, real-time performance, computational overhead, and > administrative overhead for the legitimate call source and all verifiers. > > As its priority mechanism work item, the working group will specify a > SIP header-based mechanism to verify the originator of a SIP session > is authorized to use the claimed source telephone number, where the > session is established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone > number representation. The working group will consider choices for > protecting identity information and credentials used, but will likely > be based on a digital signature mechanism that covers a set of > information in the SIP header fields, and verification will employ a > credential that contains the public key and is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism > will be derived from existing telephone number assignment and > delegation models. That is, when a telephone number or range of > telephone numbers is delegated to an entity, relevant credentials will > be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a > telephone number without compromising the global delegation scheme. > > In addition to its priority mechanism work item, the working group > will consider session establishment where there are one or more > non-SIP hops, most likely using an out-of-band mechanism. > > I feel like some words are missing here. Perhaps "providing > authorization for session establishment...." > "most likely requiring an out-of-band authorization mechanism" > > > However, the in-band and the > out-of-band mechanisms should share as much in common as possible, > especially the credentials. The in-band mechanism must be sent to the > IESG for approval and publication prior to the out-of-band mechanism. > > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is > to develop a solution for telephone numbers. > > The working group will coordinate with the Security Area on credential > management. > > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. > > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and > this working group will not propose changes to these standards. A > called party will receive an indication that the source telephone > number is unavailable in order to provide anonymity. > > Perhaps: > "In order to support anonymity, the output of the WG will provide a > mode in which the called party receives an indication..." > > > This working group, to the > extent feasible, will specify privacy-friendly mechanisms that do not > reveal any more information to user agents or third parties than a > call that does not make use of secure telephone identification mechanisms. > > Input to working group discussions shall include: > > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] > > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] > > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] > > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] > > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity > > - A threat model for the secure telephone identity mechanisms > > - A privacy analysis of the secure telephone identity mechanisms > > - A mechanism document describing the SIP end-to-end with telephone > number-based identities > > - A document describing the credentials required to support > telephone number identity authentication > > - A fallback mechanism to allow out-of-band identity establishment > during call setup > > Milestones > > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Fri Aug 9 08:54:46 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1DF21F9AB3 for ; Fri, 9 Aug 2013 08:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.121 X-Spam-Level: X-Spam-Status: No, score=-102.121 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlWQ2lEcYuP9 for ; Fri, 9 Aug 2013 08:54:41 -0700 (PDT) Received: from oproxy14-pub.mail.unifiedlayer.com (oproxy14-pub.mail.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 0659821F9A7D for ; Fri, 9 Aug 2013 08:47:25 -0700 (PDT) Received: (qmail 25836 invoked by uid 0); 9 Aug 2013 15:47:25 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 9 Aug 2013 15:47:25 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=w7/wK0+sat/SiSXxTxQJRFq65Ymm1LjUXIOQNQmxZjk=; b=OLqFt/cFt7s6SZd43yHcnMR9Zuc5T6J+YhCGzriAjluXij0NrJ2kWXBPdSxuJ8ZmlTcnmvfTlGgv+tswOco5H9NxfBHNg8nbMXolP39o4UJTW7P08P+yZXYuQ8xdNBFH; Received: from [71.114.100.16] (port=54070 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V7ouS-0003au-F8; Fri, 09 Aug 2013 09:47:25 -0600 From: "Richard Shockey" To: "'Eric Burger'" , "'Michael Hammer'" References: <00C069FD01E0324C9FFCADF539701DB3BBC2401A@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC24127@EX2K10MB1.corp.yaanatech.com> <245953A4-CF9C-4DD4-878C-11CE49F5FA07@standardstrack.com> In-Reply-To: <245953A4-CF9C-4DD4-878C-11CE49F5FA07@standardstrack.com> Date: Fri, 9 Aug 2013 11:47:21 -0400 Message-ID: <010801ce9517$bde32710$39a97530$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH0OwXpa5XwGgNDhEz4FN8wlP150wIhgpPXAlqOnYYB3H2a0JkO9MEw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:54:46 -0000 Nothing .. Its fine the way it is ... -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Eric Burger Sent: Thursday, August 08, 2013 7:54 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] Legitimate uses of third party Caller ID authorization / spoofing for outbound calling - Re: What are we trying to do, and where do we want to end up? What should go in the charter? On Aug 6, 2013, at 11:26 AM, Michael Hammer wrote: > All of them. > > > -----Original Message----- > From: Dan York [mailto:york@isoc.org] > Sent: Tuesday, August 06, 2013 11:21 AM > To: Michael Hammer; hadriel.kaplan@oracle.com; > eburger@standardstrack.com > Cc: stir@ietf.org > Subject: Re: [stir] Legitimate uses of third party Caller ID > authorization / spoofing for outbound calling - Re: What are we trying > to do, and where do we want to end up? > > Mike, > > > On 8/6/13 10:48 AM, "Michael Hammer" wrote: > >> Yes, but that doesn't mean you have to lie about the true originator >> of the call separate from what to display on caller ID or what to >> provide as a call-back number. > > Sure... but the reality is that if we have a field providing origin > identification it will probably be used for both. > > >> Many of the problems arise from conflating multiple purposes into the >> same field. > > Perhaps we need to be more clear on who is the consumer of the > field(s) we are creating: > > - Are we trying to help consumers know who is calling them? > - Are we trying to help carriers / service providers be able to track > and potentially block calls? > - Are we trying to do both? > > Dan > From housley@vigilsec.com Fri Aug 9 09:04:26 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B74711E81B9 for ; Fri, 9 Aug 2013 09:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYq71N4ANbrd for ; Fri, 9 Aug 2013 09:04:13 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4D98211E81C9 for ; Fri, 9 Aug 2013 08:58:22 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 12098F2408A for ; Fri, 9 Aug 2013 11:58:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id Z-F4LVKuD-a6 for ; Fri, 9 Aug 2013 11:58:08 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0A012F24085 for ; Fri, 9 Aug 2013 11:58:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: Date: Fri, 9 Aug 2013 11:58:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3DA449D9-79DB-4A9A-827C-D7D9777FDFA9@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:04:26 -0000 I have updated the text based on the comments from EKR and Hadriel. Is = it ready for the IESG? I am not going to bet on the Nov 2013 milestones. It is too easy yo = delay the chartering ... Russ =3D =3D =3D =3D =3D =3D =3D =3D=20 Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir The STIR working group will specify mechanisms for the validation of the source telephone number for an incoming call. Since it has become fairly easy to present an incorrect source telephone number, = a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited = commercial communications), vishing (voicemail hacking, and impersonating banks) = and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or can lead to a return call at premium rates. This working group will define mechanisms that allow verification of the authorization of the calling party to use a particular telephone number. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working = group. To date, however, true validation of the source of SIP calls has not = seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack = of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify a = SIP header-based mechanism for verification of the originator of a SIP = session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band = mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key that is associated with the one or more telephone = numbers. In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a = telephone number without compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will consider a mechanism for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be = sent to the IESG for approval and publication prior to the out-of-band mechanism. Expansion of the authorization mechanism to identities using the user@domain form are deferred since the main focus of the working group is to develop a solution for telephone numbers. The working group will coordinate with the Security Area on credential management. The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments. Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. In order to support anonymity, the working group will provide a solution in which = the called party receives an indication that the source telephone number is unavailable. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to user agents or third parties than a call that does not make use of = secure telephone identification mechanisms. Input to working group discussions shall include: - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks [RFC 3325] - Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) [RFC 4474] - Secure Call Origin Identification [draft-cooper-iab-secure-origin-00] - Secure Origin Identification: Problem Statement, Requirements, and Roadmap [draft-peterson-secure-origin-ps-00] - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-jennings-dispatch-rfc4474bis-00] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on secure telephone identity - A threat model for the secure telephone identity mechanisms - A privacy analysis of the secure telephone identity mechanisms - A document describing the SIP in-band mechanism for telephone number-based identities during call setup - A document describing the credentials required to support telephone number identity authentication - A document describing the out-of-band mechanism for telephone number-based identities during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit threat model for Informational Nov 2013 Submit in-band mechanism for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Apr 2014 Submit Privacy analysis for Informational Jun 2014 Submit out-of-band mechanism for Proposed Standard From ekr@rtfm.com Fri Aug 9 09:28:18 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4D411E8120 for ; Fri, 9 Aug 2013 09:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHBVevHwI1DR for ; Fri, 9 Aug 2013 09:28:14 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6D96321F9C59 for ; Fri, 9 Aug 2013 09:20:17 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id z10so2279655qcx.4 for ; Fri, 09 Aug 2013 09:20:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jP1q+1FYM8iV1hCSZIFZMqIqmiY8bEc1OCei1pl/FjU=; b=EXkyWgEh+lJ2tw3oYNMCbiPv6zAUxb2fgINPFb/IoOhtuF9IdQwuiESlTowAY+d1QD LtYHwfefUkDdpZsvGFsC/jucdOhHoIfIFC/xcztA4NYvL08TEeDihM7L/lVMmf/xI18U jbdI/YCHGkrB+2Ca7mjH/r/l58sJgqFeXJh22ODvC68mNetAsdorsqrwmlrnEkDPCl1E DALvBJWNK/3lNzu2RcOrJaWByDa1vZustIDKk2kdwWsuR/lvXSQ/9AmJVzkMaR2Hs7Db tU8IVN74YscyRbA8KHhirkLX9b5/P69PC3RZXG2rVoroNtDI3Y7r3YTGrx+2BRCi5jBX Hyxw== X-Gm-Message-State: ALoCoQnerzsBe01O9UdB921ZVanj3jKZOTtKxc21dO81E1iWyiil36jOi6eD6Pl34GtyjI03wLak X-Received: by 10.49.35.233 with SMTP id l9mr12257959qej.23.1376065216638; Fri, 09 Aug 2013 09:20:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Fri, 9 Aug 2013 09:19:36 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <3DA449D9-79DB-4A9A-827C-D7D9777FDFA9@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> <3DA449D9-79DB-4A9A-827C-D7D9777FDFA9@vigilsec.com> From: Eric Rescorla Date: Fri, 9 Aug 2013 09:19:36 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=047d7b671fa66d05d104e38626eb Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:28:19 -0000 --047d7b671fa66d05d104e38626eb Content-Type: text/plain; charset=ISO-8859-1 This is fine with me On Fri, Aug 9, 2013 at 8:58 AM, Russ Housley wrote: > I have updated the text based on the comments from EKR and Hadriel. Is it > ready for the IESG? > > I am not going to bet on the Nov 2013 milestones. It is too easy yo delay > the chartering ... > > Russ > > = = = = = = = = > > Name: Secure Telephone Identity Revisited (stir) > Area: RAI > > Chairs: TBD > Area Advisor: Richard Barnes > > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir > > The STIR working group will specify mechanisms for the validation of > the source telephone number for an incoming call. Since it > has become fairly easy to present an incorrect source telephone number, a > growing set of problems have emerged over the last decade. As with > email, the claimed source identity of a SIP request is not verified, > permitting unauthorized use of the source identity as part of deceptive > and coercive activities, such as robocalling (bulk unsolicited commercial > communications), vishing (voicemail hacking, and impersonating banks) and > swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, use > of an incorrect source telephone number facilitates wire fraud or can > lead to a return call at premium rates. This working group will define > mechanisms that allow verification of the authorization of the calling > party to use a particular telephone number. > > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not seen > any appreciable deployment. Several factors contributed to this lack of > success, including: failure of the problem to be seen as critical at the > time; lack of any technical means of producing a proof of authority over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack of > end-to-end SIP session establishment; and inherent operational problems > with a transitive trust model. To make deployment of this solution more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. > > As its priority mechanism work item, the working group will specify a SIP > header-based mechanism for verification of the originator of a SIP session > is > authorized to use the claimed source telephone number, where the session > is established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone number > representation. The working group will consider choices for protecting > identity information and credentials used, but will likely be based on a > digital signature mechanism that covers a set of information in the SIP > header fields, and verification will employ a credential that contains > the public key that is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a telephone > number without compromising the global delegation scheme. > > In addition to its priority mechanism work item, the working group will > consider a mechanism for verification of the originator during session > establishment in an environment with one or more non-SIP hops, most > likely requiring an out-of-band authorization mechanism. However, the > in-band and the out-of-band mechanisms should share as much in common as > possible, especially the credentials. The in-band mechanism must be sent > to the IESG for approval and publication prior to the out-of-band > mechanism. > > Expansion of the authorization mechanism to identities using the > user@domain form are deferred since the main focus of the working group > is to develop a solution for telephone numbers. > > The working group will coordinate with the Security Area on credential > management. > > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. > > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. In order to > support anonymity, the working group will provide a solution in which the > called party receives an indication that the source telephone number is > unavailable. This working group, to the extent feasible, will specify > privacy-friendly mechanisms that do not reveal any more information to > user agents or third parties than a call that does not make use of secure > telephone identification mechanisms. > > Input to working group discussions shall include: > > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] > > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] > > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] > > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] > > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situations that motivate work on secure telephone identity > > - A threat model for the secure telephone identity mechanisms > > - A privacy analysis of the secure telephone identity mechanisms > > - A document describing the SIP in-band mechanism for telephone > number-based identities during call setup > > - A document describing the credentials required to support > telephone number identity authentication > > - A document describing the out-of-band mechanism for telephone > number-based identities during call setup > > Milestones > > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7b671fa66d05d104e38626eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is fine with me

<= br>
On Fri, Aug 9, 2013 at 8:58 AM, Russ Housley = <housley@vigilsec.com> wrote:
I have updated the text based on the comment= s from EKR and Hadriel. =A0Is it ready for the IESG?

I am not going to bet on the Nov 2013 milestones. =A0It is too easy yo dela= y the chartering ...

Russ

=3D =3D =3D =3D =3D =3D =3D =3D

Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: Richard Barnes

Mailing list: stir@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

The STIR working group will specify mechanisms for the validation of
the source telephone number for an incoming call. =A0Since it
has become fairly easy to present an incorrect source tel= ephone number, a
growing set of problems have emerged over the last decade. =A0As with
email, the claimed source identity of a SIP request is not verified,
permitting unauthorized use of the source identity as part of deceptive
and coercive activities, such as robocalling (bulk unsolicited commercial
communications), vishing (voicemail hacking, and impersonating banks)= and
swatting (impersonating callers to emergency services to = stimulate
unwarranted large scale law enforcement deployments). =A0In addition, use
of an incorrect source telephone number facilitates wire fraud or can=
lead to a return call at premium rates. =A0This working g= roup will define
mechanisms that allow verification of the authorization of the callin= g
party to use a particular telephone number.

SIP is one of the main VoIP technologies used by pa= rties that want to
present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP
communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. =A0Several factors contributed to this lack of<= br> success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474
with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems
with a transitive trust model. =A0To make deployment of this solution more<= br> likely, consideration must be given to latency, real-time performance,
computational overhead, and administrative overhead for the legitimate
call source and all verifiers.

As its priority mechanism work item, the working group will specify a SIP
header-based mechanism for verification of the originator of a SIP se= ssion is
authorized to use the claimed source telephone number, wh= ere the session
is established with SIP end to end. =A0This is called an in-band mechanism.=
The mechanism will use a canonical telephone number representation
specified by the working group, including any mappings that might be
needed between the SIP header fields and the canonical telephone number
representation. =A0The working group will consider choices for protecting identity information and credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP
header fields, and verification will employ a credential that contains
the public key that is associated with the one or more telephone numb= ers.
In order to be authoritative, credentials used with this = mechanism will
be derived from existing telephone number assignment and delegation
models. =A0That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or
modified) to reflect such delegation. =A0The mechanism must allow a
telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme.

In addition to its priority mechanism work item, the working group will
consider a mechanism for verification of the originator during sessio= n
establishment in an environment with one or more non-SIP hops, most
likely requiring an out-of-band authorization mechanism. =A0However, the
in-band and the out-of-band mechanisms should share as mu= ch in common as
possible, especially the credentials. =A0The in-band mechanism must be sent=
to the IESG for approval and publication prior to the out-of-band
mechanism.

Expansion of the authorization mechanism to identities using the
user@domain form are deferred since the main focus of the working gro= up
is to develop a solution for telephone numbers.

The working group will coordinate with the Security Area on credential
management.

The working group will coordinate with other working groups in the RAI
Area regarding signaling through existing deployments.

Authentication and authorization of identity is clo= sely linked to
privacy, and these security features sometimes come at the cost of
privacy. =A0Anonymous calls are already defined in SIP standards, and this<= br>
working group will not propose changes to these standards. =A0In orde= r to
support anonymity, the working group will provide a solution in which the called party receives an indication that the source telephone number is
unavailable. =A0This working group, to the extent feasible, will specify
privacy-friendly mechanisms that do not reveal any more i= nformation to
user agents or third parties than a call that does not make use of se= cure
telephone identification mechanisms.

Input to working group discussions shall include:

=A0- Private Extensions to the Session Initiation Protocol (SIP)
=A0 =A0for Asserted Identity within Trusted Networks
=A0 =A0[RFC 3325]

=A0- Enhancements for Authenticated Identity Management in the
=A0 =A0Session Initiation Protocol (SIP)
=A0 =A0[RFC 4474]

=A0- Secure Call Origin Identification
=A0 =A0[draft-cooper-iab-secure-origin-00]

=A0- Secure Origin Identification: Problem Statement, Requirements,
=A0 =A0and Roadmap
=A0 =A0[draft-peterson-secure-origin-ps-00]

=A0- Authenticated Identity Management in the Session Initiation
=A0 =A0Protocol (SIP)
=A0 =A0[draft-jennings-dispatch-rfc4474bis-00]

The working group will deliver the following:

=A0- A problem statement detailing the deployment environment and
=A0 =A0situations that motivate work on secure telephone identity

=A0- A threat model for the secure telephone identity mechanisms

=A0- A privacy analysis of the secure telephone identity mechanisms

=A0- A document describing the SIP in-band mechanism for telephone =A0 =A0number-based identities during call setup

=A0- A document describing the credentials required to support
=A0 =A0telephone number identity authentication

=A0- A document describing the out-of-band mechanism for telephone =A0 =A0number-based identities during call setup

Milestones

Sep 2013 =A0 Submit problem statement for Informational
Nov 2013 =A0 Submit threat model for Informational
Nov 2013 =A0 Submit in-band mechanism for Proposed Standard
Feb 2014 =A0 Submit credential specification for Proposed Standard
Apr 2014 =A0 Submit Privacy analysis for Informational
Jun 2014 =A0 Submit out-of-band mechanism for Proposed Standard

_____________________________= __________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--047d7b671fa66d05d104e38626eb-- From hadriel.kaplan@oracle.com Fri Aug 9 10:04:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA63411E811A for ; Fri, 9 Aug 2013 10:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEx+ZFDD2gfZ for ; Fri, 9 Aug 2013 10:04:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0422711E8127 for ; Fri, 9 Aug 2013 09:59:11 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r79GxA4V032219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 16:59:11 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79Gx7Le007696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 16:59:10 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79Gx7oK014838; Fri, 9 Aug 2013 16:59:07 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 09:59:07 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_8EEC0CE9-61E2-49C1-A69A-2A29DB469911" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 9 Aug 2013 12:59:05 -0400 Message-Id: <1FC7501F-28C7-4B7F-8CCF-E5EB30005D5B@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> <3DA449D9-79DB-4A9A-827C-D7D9777FDFA9@vigilsec.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:04:36 -0000 --Apple-Mail=_8EEC0CE9-61E2-49C1-A69A-2A29DB469911 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Same here. -hadriel On Aug 9, 2013, at 12:19 PM, Eric Rescorla wrote: > This is fine with me >=20 >=20 > On Fri, Aug 9, 2013 at 8:58 AM, Russ Housley = wrote: > I have updated the text based on the comments from EKR and Hadriel. = Is it ready for the IESG? >=20 > I am not going to bet on the Nov 2013 milestones. It is too easy yo = delay the chartering ... >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D =3D =3D >=20 > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: Richard Barnes >=20 > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir >=20 > The STIR working group will specify mechanisms for the validation of > the source telephone number for an incoming call. Since it > has become fairly easy to present an incorrect source telephone = number, a > growing set of problems have emerged over the last decade. As with > email, the claimed source identity of a SIP request is not verified, > permitting unauthorized use of the source identity as part of = deceptive > and coercive activities, such as robocalling (bulk unsolicited = commercial > communications), vishing (voicemail hacking, and impersonating banks) = and > swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, = use > of an incorrect source telephone number facilitates wire fraud or can > lead to a return call at premium rates. This working group will = define > mechanisms that allow verification of the authorization of the calling > party to use a particular telephone number. >=20 > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone = number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working = group. > To date, however, true validation of the source of SIP calls has not = seen > any appreciable deployment. Several factors contributed to this lack = of > success, including: failure of the problem to be seen as critical at = the > time; lack of any technical means of producing a proof of authority = over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack = of > end-to-end SIP session establishment; and inherent operational = problems > with a transitive trust model. To make deployment of this solution = more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. >=20 > As its priority mechanism work item, the working group will specify a = SIP > header-based mechanism for verification of the originator of a SIP = session is > authorized to use the claimed source telephone number, where the = session > is established with SIP end to end. This is called an in-band = mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone = number > representation. The working group will consider choices for = protecting > identity information and credentials used, but will likely be based on = a > digital signature mechanism that covers a set of information in the = SIP > header fields, and verification will employ a credential that contains > the public key that is associated with the one or more telephone = numbers. > In order to be authoritative, credentials used with this mechanism = will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone = numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a = telephone > number without compromising the global delegation scheme. >=20 > In addition to its priority mechanism work item, the working group = will > consider a mechanism for verification of the originator during session > establishment in an environment with one or more non-SIP hops, most > likely requiring an out-of-band authorization mechanism. However, the > in-band and the out-of-band mechanisms should share as much in common = as > possible, especially the credentials. The in-band mechanism must be = sent > to the IESG for approval and publication prior to the out-of-band > mechanism. >=20 > Expansion of the authorization mechanism to identities using the > user@domain form are deferred since the main focus of the working = group > is to develop a solution for telephone numbers. >=20 > The working group will coordinate with the Security Area on credential > management. >=20 > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. >=20 > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and = this > working group will not propose changes to these standards. In order = to > support anonymity, the working group will provide a solution in which = the > called party receives an indication that the source telephone number = is > unavailable. This working group, to the extent feasible, will specify > privacy-friendly mechanisms that do not reveal any more information to > user agents or third parties than a call that does not make use of = secure > telephone identification mechanisms. >=20 > Input to working group discussions shall include: >=20 > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] >=20 > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] >=20 > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] >=20 > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] >=20 > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] >=20 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situations that motivate work on secure telephone identity >=20 > - A threat model for the secure telephone identity mechanisms >=20 > - A privacy analysis of the secure telephone identity mechanisms >=20 > - A document describing the SIP in-band mechanism for telephone > number-based identities during call setup >=20 > - A document describing the credentials required to support > telephone number identity authentication >=20 > - A document describing the out-of-band mechanism for telephone > number-based identities during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_8EEC0CE9-61E2-49C1-A69A-2A29DB469911 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Same here.

-hadriel

On Aug 9, 2013, at 12:19 PM, Eric Rescorla <ekr@rtfm.com> wrote:

This is fine with me


On Fri, Aug 9, 2013 at 8:58 AM, Russ Housley <housley@vigilsec.com> wrote:
I have updated the text based on the comments from EKR and Hadriel.  Is it ready for the IESG?

I am not going to bet on the Nov 2013 milestones.  It is too easy yo delay the chartering ...

Russ

= = = = = = = =

Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: Richard Barnes

Mailing list: stir@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

The STIR working group will specify mechanisms for the validation of
the source telephone number for an incoming call.  Since it
has become fairly easy to present an incorrect source telephone number, a
growing set of problems have emerged over the last decade.  As with
email, the claimed source identity of a SIP request is not verified,
permitting unauthorized use of the source identity as part of deceptive
and coercive activities, such as robocalling (bulk unsolicited commercial
communications), vishing (voicemail hacking, and impersonating banks) and
swatting (impersonating callers to emergency services to stimulate
unwarranted large scale law enforcement deployments).  In addition, use
of an incorrect source telephone number facilitates wire fraud or can
lead to a return call at premium rates.  This working group will define
mechanisms that allow verification of the authorization of the calling
party to use a particular telephone number.

SIP is one of the main VoIP technologies used by parties that want to
present an incorrect origin, in this context an origin telephone number.
Several previous efforts have tried to secure the origins of SIP
communications, including RFC 3325, RFC 4474, and the VIPR working group.
To date, however, true validation of the source of SIP calls has not seen
any appreciable deployment.  Several factors contributed to this lack of
success, including: failure of the problem to be seen as critical at the
time; lack of any technical means of producing a proof of authority over
telephone numbers; misalignment of the mechanisms proposed by RFC 4474
with the complex deployment environment that has emerged for SIP; lack of
end-to-end SIP session establishment; and inherent operational problems
with a transitive trust model.  To make deployment of this solution more
likely, consideration must be given to latency, real-time performance,
computational overhead, and administrative overhead for the legitimate
call source and all verifiers.

As its priority mechanism work item, the working group will specify a SIP
header-based mechanism for verification of the originator of a SIP session is
authorized to use the claimed source telephone number, where the session
is established with SIP end to end.  This is called an in-band mechanism.
The mechanism will use a canonical telephone number representation
specified by the working group, including any mappings that might be
needed between the SIP header fields and the canonical telephone number
representation.  The working group will consider choices for protecting
identity information and credentials used, but will likely be based on a
digital signature mechanism that covers a set of information in the SIP
header fields, and verification will employ a credential that contains
the public key that is associated with the one or more telephone numbers.
In order to be authoritative, credentials used with this mechanism will
be derived from existing telephone number assignment and delegation
models.  That is, when a telephone number or range of telephone numbers
is delegated to an entity, relevant credentials will be generated (or
modified) to reflect such delegation.  The mechanism must allow a
telephone number holder to further delegate and revoke use of a telephone
number without compromising the global delegation scheme.

In addition to its priority mechanism work item, the working group will
consider a mechanism for verification of the originator during session
establishment in an environment with one or more non-SIP hops, most
likely requiring an out-of-band authorization mechanism.  However, the
in-band and the out-of-band mechanisms should share as much in common as
possible, especially the credentials.  The in-band mechanism must be sent
to the IESG for approval and publication prior to the out-of-band
mechanism.

Expansion of the authorization mechanism to identities using the
user@domain form are deferred since the main focus of the working group
is to develop a solution for telephone numbers.

The working group will coordinate with the Security Area on credential
management.

The working group will coordinate with other working groups in the RAI
Area regarding signaling through existing deployments.

Authentication and authorization of identity is closely linked to
privacy, and these security features sometimes come at the cost of
privacy.  Anonymous calls are already defined in SIP standards, and this
working group will not propose changes to these standards.  In order to
support anonymity, the working group will provide a solution in which the
called party receives an indication that the source telephone number is
unavailable.  This working group, to the extent feasible, will specify
privacy-friendly mechanisms that do not reveal any more information to
user agents or third parties than a call that does not make use of secure
telephone identification mechanisms.

Input to working group discussions shall include:

 - Private Extensions to the Session Initiation Protocol (SIP)
   for Asserted Identity within Trusted Networks
   [RFC 3325]

 - Enhancements for Authenticated Identity Management in the
   Session Initiation Protocol (SIP)
   [RFC 4474]

 - Secure Call Origin Identification
   [draft-cooper-iab-secure-origin-00]

 - Secure Origin Identification: Problem Statement, Requirements,
   and Roadmap
   [draft-peterson-secure-origin-ps-00]

 - Authenticated Identity Management in the Session Initiation
   Protocol (SIP)
   [draft-jennings-dispatch-rfc4474bis-00]

The working group will deliver the following:

 - A problem statement detailing the deployment environment and
   situations that motivate work on secure telephone identity

 - A threat model for the secure telephone identity mechanisms

 - A privacy analysis of the secure telephone identity mechanisms

 - A document describing the SIP in-band mechanism for telephone
   number-based identities during call setup

 - A document describing the credentials required to support
   telephone number identity authentication

 - A document describing the out-of-band mechanism for telephone
   number-based identities during call setup

Milestones

Sep 2013   Submit problem statement for Informational
Nov 2013   Submit threat model for Informational
Nov 2013   Submit in-band mechanism for Proposed Standard
Feb 2014   Submit credential specification for Proposed Standard
Apr 2014   Submit Privacy analysis for Informational
Jun 2014   Submit out-of-band mechanism for Proposed Standard

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--Apple-Mail=_8EEC0CE9-61E2-49C1-A69A-2A29DB469911-- From pkyzivat@alum.mit.edu Fri Aug 9 10:14:27 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02D421F99A8 for ; Fri, 9 Aug 2013 10:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdClrFjUxBc0 for ; Fri, 9 Aug 2013 10:14:22 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF4021F9A49 for ; Fri, 9 Aug 2013 10:08:54 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id AgcT1m0060EZKEL5Ch8s78; Fri, 09 Aug 2013 17:08:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id Ah8s1m00J3ZTu2S3Mh8sqB; Fri, 09 Aug 2013 17:08:52 +0000 Message-ID: <52052223.1000508@alum.mit.edu> Date: Fri, 09 Aug 2013 19:08:51 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> <702EA082-43B7-490D-B909-00630A195CE4@vigilsec.com> <520114D6.2050205@dcrocker.net> <97FC9B06-AB16-46BE-B46F-B2E9576F0FF2@vigilsec.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376068132; bh=c3FXh0LHR2fWAbmJMhyYR27moW80aLgqCB9i67cFQ8c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IDGb/sngB+3NQTGcQApGu5Ddm5n9tVCf5qBviPt7HI9ANnXLEdZGDk9iL0MzN8EDg 6mjgZked93Pi4M60wvlRHiCvzKKagg3E6OqBRDhjwpzODWCLqilg/vFwTziRcTBbUK WgiKFEH9VAl28Y5Ve3t2jMqqexMzPftE8Bzp7486zvSoImiqq+EznEy0TVDtaA3bfV M+wV7YsAZLX0awPW+4bt7pn6q6fmN2bPmYtJkuMdJhZ8uxVfY2v2Bf1luAc18nHQsx dJKb+4jImh2HqWf2T2nI010NeBvmchSWB6whXMUEi0IjWX3PpYiBti0YuiHCWs1xWa y1s8uiVpsqztA== Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:14:28 -0000 On 8/9/13 1:54 AM, Eric Burger wrote: > On Aug 6, 2013, at 1:12 PM, Russ Housley wrote: >> Dave: >> >>>> The threat document is quite different if it cover an in-band mechanism or both an in-band and an out-of-band mechanism. Do you have any thoughts on this? Do you have proposed charter text? >>> >>> No doubt it's my naivete about the technical side of security work, but it isn't obvious to me why your assertion is correct. Please explain the nature of the differences that you see. >>> >>> By way of example, imagine an out-of-band mechanism that merely takes the in-band signature and stashes it somewhere, much like a cookie mechanism. The storage environment can see the retrieval attributes in the clear -- the same as any other transit handling node -- I suppose, but the rest of the information won't be accessible to it. >>> >>> Nevermind that, even before we have the charter saying that out-of-band is to be deferred, we have yet-another introduction of it into initial technical discussions. >> >> The threat environment for in-band is simpler; it contains fewer entities to consider in the analysis. >> >> The threat environment for out-of-band is more complex; it contains all of the entities in the in-band case as well as SBCs and PSTN entities. > > I thought the justification for out-of-band is it avoided the SBC's, the carriers, and so on. No? While an over the top call would avoid much of the tracking, it only works if the callee will accept an over the top call. And today that is very rare. But maybe some key callees that have a need to accept anonymous calls (e.g., the police) could actively decide to do so. But that doesn't work unless most callers can originate such calls. And if callees that accept them are rare, then the mechanism isn't likely to be widely deployed. Thanks, Paul From pkyzivat@alum.mit.edu Fri Aug 9 10:43:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DFE21F9C46 for ; Fri, 9 Aug 2013 10:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abFgiMo4e87a for ; Fri, 9 Aug 2013 10:43:40 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id AD3C021F9C7E for ; Fri, 9 Aug 2013 10:36:37 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta05.westchester.pa.mail.comcast.net with comcast id Ablg1m0040mv7h055hcYTl; Fri, 09 Aug 2013 17:36:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id AhcX1m00u3ZTu2S3XhcXJZ; Fri, 09 Aug 2013 17:36:31 +0000 Message-ID: <5205289F.8070408@alum.mit.edu> Date: Fri, 09 Aug 2013 19:36:31 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <1E587684-70A3-4782-AD7E-98169F3BB0B1@standardstrack.com> <520100AC.7040601@alum.mit.edu> <057B0D85-E27C-4497-A0D6-CE209D909440@standardstrack.com> In-Reply-To: <057B0D85-E27C-4497-A0D6-CE209D909440@standardstrack.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376069792; bh=MMMOb/dZokYuMqL51s2/ZGfoencIZKOqvSL0v4SIUeY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mY5nbNiyAqn8cyJZLAOlhvxocHPlBBRIkdEyxGaEmE8ADn1olv8xu+riu9kA4EKxu coxgtiUxmZIYF69DYA0Q5bZH83EJjMCWsQO1tMubbkOSEpO1+8YbnBvPFuIAkCTJu6 4BVQIhJrW2QewHGNewX/a0YXpb2bHo9Xr9fVp+mp3evvRX4Q1YSo8XQwOCF5pnRgUo CJt5LMZNXjDqk7x/YIfsfEJMQHeTKJD64XwGfSDfIPhYL7uYumVM8EpDL1VCDQrbuO iJkXfZFntiSaqEULmd4wtS7LwHJ+pZXoHaJINFiZTACrx6nxojLKGKdoCphcBUhvo1 IRhCLTS0Y4/AQ== Subject: Re: [stir] 15ms??? Where the heck did that come from? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:43:45 -0000 On 8/9/13 1:54 AM, Eric Burger wrote: > And out of band can be parallel. However, here's an interesting thought: the client is most likely going to 183 the call until it gets the authenticated response. That means service providers are going to be holding the bag for Xms extra for, if STIR is successful, every call. That's hundreds of millions of minutes per month. Good thing we are not talking TDM where DS0's would be allocated and blocked! And do you expect the cost of those extra ms of just waiting to be significant? How does that trade off against reducing the processing of unwanted calls? Thanks, Paul > On Aug 6, 2013, at 9:57 AM, Paul Kyzivat wrote: > >> The ideal is that this be done in *parallel*, not *series* with other processing, so that most of the cost doesn't normally add to the delay. >> >> Thanks, >> Paul >> >> On 8/6/13 1:38 PM, Hadriel Kaplan wrote: >>> >>> Agreed - the budget is not as low as 15ms, but nowhere near as high as 4 seconds. It's actually quite hard to come up with a hard limit though, as a general requirement for STIR for all scenarios. Generally I just think of it as: "as low as we can possibly make it". >>> >>> Some people have been talking about it from the perspective of acceptable post-dial-delay (PDD), but I think that's the wrong way to think about it - because STIR is adding additional time to whatever is already deployed today. So the real question is how much *additional* time do we think STIR can introduce, without being a barrier to adoption. That's why for me the topic boils down to "make it super-frigging' fast". >>> >>> As an equipment vendor, for example, my employer gets requirements for SIP message processing in the order of single-digit milliseconds if there's no external DB query. Even when we query external databases, we're sometimes required to stop waiting for a DB answer after only tens of milliseconds (or less than 100ms), and forward the call on regardless. This may be because some wholesale carrier SLAs are measured on post-dial-delay; or it may just be because so many systems are involved in call processing, and the cumulative delay would become so untenable, that the carriers decide to require a consistent common max value for all systems. I don't know for sure. Either way, carriers are very sensitive to call delays. >>> >>> [As an aside for those who care: according to ITU E.721, the mean delay budget for end-to-end PDD is 3 seconds for local calls, 5 seconds for national long-distance, and 8 seconds for international. But that spec is really conservative and is based on phone-to-phone time. For the SS7 network, a different spec (E.723) gives the end-to-end PDD across the SS7 system as 0.9 seconds for local calls, 2.3 seconds for long-distance, and 4 seconds for international. Mobile phones/networks have a different set of values, I believe. But again, looking at these numbers provides a false sense of time budget for STIR.] >>> >>> -hadriel >>> >>> >>> On Aug 5, 2013, at 4:37 PM, Eric Burger wrote: >>> >>>> In the STIR BOF I mentioned that the time budget for *additional* processing in the PSTN world would be on the order of 15ms. I need to put a LOT of context around that statement. >>>> >>>> Twenty years ago (NOT TODAY), routing special PSTN calls, like free phone or virtual networks, had a very tight time budget. There were both government performance mandates and consumer drivers that ensured carriers routed calls quickly. The big driver is callers might wait up to 2500ms before they would abandon the call. At my company, the saying we had was we never want one of our customers to say, "Why did I ever switch from brand A?" as they hung up the phone and redialed. >>>> >>>> Given the latencies of local switches routing to long distance switches, the latencies of breaking out call signaling to make a dozen or so data base lookups, and returning the result so the call could be routed to its destination, our total processing budget was 70ms. That was the days of 30ms access time disks, so you can see the problem. >>>> >>>> So, on the one hand, in an IP environment we have a lot more time than 15ms to do authentication steps, as we can do that work in parallel to other routing logic. We are not restricted to adding on the exchanges and algorithms in sequence to other routing processing. >>>> >>>> On the other hand, the statement that the budget is 10000ms is beyond reality. Even in a World of Warcraft chat room, no one is going to wait 10 seconds in the hope a connection request is successful. Granted, mobile phones and early VoIP systems have trained users to have a little more patience than 2500ms. However, to expect a user, in a PSTN emulation environment, to hang on for more than 4000ms or 5000ms is wishful thinking._______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From hadriel.kaplan@oracle.com Fri Aug 9 10:45:29 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3A711E81B7 for ; Fri, 9 Aug 2013 10:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aVsEz2Jk7jn for ; Fri, 9 Aug 2013 10:45:23 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 87D8021F8C4C for ; Fri, 9 Aug 2013 10:38:38 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r79HcZ9n031224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 17:38:37 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79HcYQW026166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 17:38:35 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79HcYxW000923; Fri, 9 Aug 2013 17:38:34 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 10:38:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <52052223.1000508@alum.mit.edu> Date: Fri, 9 Aug 2013 13:38:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> <702EA082-43B7-490D-B909-00630A195CE4@vigilsec.com> <520114D6.2050205@dcrocker.net> <97FC9B06-AB16-46BE-B46F-B2E9576F0FF2@vigilsec.com> <52052223.1000508@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:45:29 -0000 On Aug 9, 2013, at 1:08 PM, Paul Kyzivat wrote: > On 8/9/13 1:54 AM, Eric Burger wrote: >>=20 >> I thought the justification for out-of-band is it avoided the SBC's, = the carriers, and so on. No? >=20 > While an over the top call would avoid much of the tracking, it only = works if the callee will accept an over the top call. And today that is = very rare. The currently proposed straw-man for how the out-of-band would work is = the call signaling would continue to go its current way and continue to = do its current thing; but the originator of the call (or some entity on = its behalf) would publish the source number verification info to an = out-of-band registry, and then the receiver of the call would go = retrieve it from there to verify the caller's source identity. (I'm = simplifying, but that's the general concept) So in that way Eric's right - its main advantage is it can bypass the = service providers. Of course once such a thing is deployed it could be used for the call = signaling itself, and that's even stated in the straw-man draft for it. -hadriel From hadriel.kaplan@oracle.com Fri Aug 9 11:16:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752C921F9E95 for ; Fri, 9 Aug 2013 11:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DamLdpZg5fCS for ; Fri, 9 Aug 2013 11:16:43 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6C43011E8119 for ; Fri, 9 Aug 2013 11:11:13 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r79IBAC4029335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 18:11:11 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79IB9wY003935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 18:11:10 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79IB9pt006719; Fri, 9 Aug 2013 18:11:09 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 11:11:09 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <520100AC.7040601@alum.mit.edu> Date: Fri, 9 Aug 2013 14:11:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <313BBB5B-709E-4355-8337-32911F43F925@oracle.com> References: <1E587684-70A3-4782-AD7E-98169F3BB0B1@standardstrack.com> <520100AC.7040601@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org Subject: Re: [stir] 15ms??? Where the heck did that come from? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:16:48 -0000 Sure, that's the ideal. In practice, it won't and can't be ideal. For = example, even if the system you decide to do verification in already = delays calls for 100ms for other database lookup reasons, if the STIR = database lookup takes 500ms then the extra 400ms of time is 400ms of = additional PDD delay time. And that's assuming you're doing it on a = system that has such delay already today. But none of that was my point. My point was some people have been = talking about STIR overhead as being unimportant because users expect a = X number of seconds of PDD so we have a X seconds to play with, and I = was just saying "no, you don't have X". -hadriel On Aug 6, 2013, at 9:57 AM, Paul Kyzivat wrote: > The ideal is that this be done in *parallel*, not *series* with other = processing, so that most of the cost doesn't normally add to the delay. >=20 > Thanks, > Paul >=20 > On 8/6/13 1:38 PM, Hadriel Kaplan wrote: >>=20 >> Agreed - the budget is not as low as 15ms, but nowhere near as high = as 4 seconds. It's actually quite hard to come up with a hard limit = though, as a general requirement for STIR for all scenarios. Generally = I just think of it as: "as low as we can possibly make it". >>=20 >> Some people have been talking about it from the perspective of = acceptable post-dial-delay (PDD), but I think that's the wrong way to = think about it - because STIR is adding additional time to whatever is = already deployed today. So the real question is how much *additional* = time do we think STIR can introduce, without being a barrier to = adoption. That's why for me the topic boils down to "make it = super-frigging' fast". >>=20 >> As an equipment vendor, for example, my employer gets requirements = for SIP message processing in the order of single-digit milliseconds if = there's no external DB query. Even when we query external databases, = we're sometimes required to stop waiting for a DB answer after only tens = of milliseconds (or less than 100ms), and forward the call on = regardless. This may be because some wholesale carrier SLAs are = measured on post-dial-delay; or it may just be because so many systems = are involved in call processing, and the cumulative delay would become = so untenable, that the carriers decide to require a consistent common = max value for all systems. I don't know for sure. Either way, carriers = are very sensitive to call delays. >>=20 >> [As an aside for those who care: according to ITU E.721, the mean = delay budget for end-to-end PDD is 3 seconds for local calls, 5 seconds = for national long-distance, and 8 seconds for international. But that = spec is really conservative and is based on phone-to-phone time. For = the SS7 network, a different spec (E.723) gives the end-to-end PDD = across the SS7 system as 0.9 seconds for local calls, 2.3 seconds for = long-distance, and 4 seconds for international. Mobile phones/networks = have a different set of values, I believe. But again, looking at these = numbers provides a false sense of time budget for STIR.] >>=20 >> -hadriel >>=20 >>=20 >> On Aug 5, 2013, at 4:37 PM, Eric Burger = wrote: >>=20 >>> In the STIR BOF I mentioned that the time budget for *additional* = processing in the PSTN world would be on the order of 15ms. I need to = put a LOT of context around that statement. >>>=20 >>> Twenty years ago (NOT TODAY), routing special PSTN calls, like free = phone or virtual networks, had a very tight time budget. There were both = government performance mandates and consumer drivers that ensured = carriers routed calls quickly. The big driver is callers might wait up = to 2500ms before they would abandon the call. At my company, the saying = we had was we never want one of our customers to say, "Why did I ever = switch from brand A?" as they hung up the phone and redialed. >>>=20 >>> Given the latencies of local switches routing to long distance = switches, the latencies of breaking out call signaling to make a dozen = or so data base lookups, and returning the result so the call could be = routed to its destination, our total processing budget was 70ms. That = was the days of 30ms access time disks, so you can see the problem. >>>=20 >>> So, on the one hand, in an IP environment we have a lot more time = than 15ms to do authentication steps, as we can do that work in parallel = to other routing logic. We are not restricted to adding on the exchanges = and algorithms in sequence to other routing processing. >>>=20 >>> On the other hand, the statement that the budget is 10000ms is = beyond reality. Even in a World of Warcraft chat room, no one is going = to wait 10 seconds in the hope a connection request is successful. = Granted, mobile phones and early VoIP systems have trained users to have = a little more patience than 2500ms. However, to expect a user, in a PSTN = emulation environment, to hang on for more than 4000ms or 5000ms is = wishful thinking._______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From eburger@standardstrack.com Fri Aug 9 15:26:28 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE88721F9AEB for ; Fri, 9 Aug 2013 15:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytbM+qGaArAW for ; Fri, 9 Aug 2013 15:26:23 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7FA1F0D10 for ; Fri, 9 Aug 2013 15:18:18 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:59984 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7v0i-00052g-5N for stir@ietf.org; Fri, 09 Aug 2013 15:18:16 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_7FB31DF2-754D-40BB-A71B-D2783485FA0E"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <691C8CC2-B20F-4684-A6E4-52D4D0F00657@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 9 Aug 2013 18:18:20 -0400 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> To: stir@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:26:29 -0000 --Apple-Mail=_7FB31DF2-754D-40BB-A71B-D2783485FA0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It is one thing for the regulators to say "be bad." It is another thing = for the regulators to say "do bad things because the IETF says it is = good." On Aug 9, 2013, at 12:00 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger = wrote: > On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan = wrote: > > On Aug 5, 2013, at 4:36 PM, Eric Burger = wrote: > > I agree we are not looking at a national security private network = analysis. However, we are talking about the potential end of any privacy = or anonymity for ANY Internet application, more especially Internet = multimedia application. > > > > How so? Obviously we could theoretically create some mechanism that = took all call information from/to everyone and posted it to wikileaks or > > whatever, but I don't think we're that stupid. (nor do I think it = would get published by the IETF, nor would anyone use it if we did) > > > > No one is proposing, for example, that anonymous calls no longer = remain anonymous. Nor that one can't make anonymous calls. >=20 > Actually, we are. We are talking about "official" calling. Otherwise, = we would have p2psip and there would not be regulators in the middle. It = would not be hard to imaging regulators banning anonymous calling, as = the bad guys all use anonymous calling and grandpa still answers the = call and hands over his life savings to the nice lady on the phone. > =20 > I'm not following this argument at all. The regulators could = presumably > require this now. How does STIR change the situation? >=20 > -Ekr >=20 >=20 --Apple-Mail=_7FB31DF2-754D-40BB-A71B-D2783485FA0E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA5MjIxODIxWjAjBgkqhkiG9w0BCQQxFgQU cyKAXywyphBSAVNuenAuDvGlAhQwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAP6nRmLwUgJLetad5wIvlFAhUruyOSa2Hptcpx55YToHUGoih5tCT dhqQh022F5K9wx+HmZv+csC3TmPQse0G91f2KFjPtyIN9MgYGVzCuXwxxh/mhfYbaTiUJt2cYRaG H+NXNwMLMmub/ixdOZKEQ5A1kbpxR9MY3pRYczuKRTSIruCL3ncufpmKnc9mKurdGZAj4o3v9w/Z eidjMFLJhdEAmOvfggypcjEtS3ILwqvIKzzCCAAAERftzA74MfFh3fyhBmsZFtAEE7WXHdcPCXY4 T06zrKJl3sflE5n9jswfo0RiDBBHWTL6gR50Au81J+MYv5zBE8SogAeWebB+aAAAAAAAAA== --Apple-Mail=_7FB31DF2-754D-40BB-A71B-D2783485FA0E-- From eburger@standardstrack.com Fri Aug 9 15:45:08 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BF011E8130 for ; Fri, 9 Aug 2013 15:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.052 X-Spam-Level: X-Spam-Status: No, score=-102.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYcBDhQRk1Hj for ; Fri, 9 Aug 2013 15:45:03 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id CE56821F9B25 for ; Fri, 9 Aug 2013 15:37:42 -0700 (PDT) Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:60233 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V7vJT-0008Uo-TL for stir@ietf.org; Fri, 09 Aug 2013 15:37:40 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_A91672EB-7A8B-4FDD-9404-329A459527AE"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <5B9C030E-E44F-4194-9B5D-99413C6B24EA@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 9 Aug 2013 18:37:45 -0400 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> <3DA449D9-79DB-4A9A-827C-D7D9777FDFA9@vigilsec.com> <8D4524DD-F5BD-482C-835B-B9DB2D154B4D@georgetown.edu> To: IETF STIR Mail List In-Reply-To: <8D4524DD-F5BD-482C-835B-B9DB2D154B4D@georgetown.edu> X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 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 X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:45:08 -0000 --Apple-Mail=_A91672EB-7A8B-4FDD-9404-329A459527AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I still think it is insane to say we will deliver the threat model and = the solution in parallel, but Hadriel and I have a $2 vs $20M side bet = going on :-) 10,000,000:1 odds is pretty good. I also think it is silly to have a year of work (really three) on in = band and have out of band be in the charter. Just say no and do that = later or as individual work. If the individual work matures faster than = in-band, they get their own group and I can have another side bet (like = XCON and MEDIACTRL) that I can make book on. [Although admittedly, the = XCON versus MEDIACTRL was the *ONLY* bet I have lost so far.] Let's stop pontificating and get to work. Your AD's can beat you about = the head about insane dates. The work is what is important. On Aug 9, 2013, at 11:58 AM, Russ Housley wrote: > I have updated the text based on the comments from EKR and Hadriel. = Is it ready for the IESG? >=20 > I am not going to bet on the Nov 2013 milestones. It is too easy yo = delay the chartering ... >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D =3D =3D=20 >=20 > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: Richard Barnes >=20 > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir >=20 > The STIR working group will specify mechanisms for the validation of > the source telephone number for an incoming call. Since it > has become fairly easy to present an incorrect source telephone = number, a > growing set of problems have emerged over the last decade. As with > email, the claimed source identity of a SIP request is not verified, > permitting unauthorized use of the source identity as part of = deceptive > and coercive activities, such as robocalling (bulk unsolicited = commercial > communications), vishing (voicemail hacking, and impersonating banks) = and > swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, = use > of an incorrect source telephone number facilitates wire fraud or can > lead to a return call at premium rates. This working group will = define > mechanisms that allow verification of the authorization of the calling > party to use a particular telephone number. >=20 > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone = number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working = group. > To date, however, true validation of the source of SIP calls has not = seen > any appreciable deployment. Several factors contributed to this lack = of > success, including: failure of the problem to be seen as critical at = the > time; lack of any technical means of producing a proof of authority = over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack = of > end-to-end SIP session establishment; and inherent operational = problems > with a transitive trust model. To make deployment of this solution = more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. >=20 > As its priority mechanism work item, the working group will specify a = SIP > header-based mechanism for verification of the originator of a SIP = session is > authorized to use the claimed source telephone number, where the = session > is established with SIP end to end. This is called an in-band = mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone = number > representation. The working group will consider choices for = protecting > identity information and credentials used, but will likely be based on = a > digital signature mechanism that covers a set of information in the = SIP > header fields, and verification will employ a credential that contains > the public key that is associated with the one or more telephone = numbers. > In order to be authoritative, credentials used with this mechanism = will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone = numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a = telephone > number without compromising the global delegation scheme. >=20 > In addition to its priority mechanism work item, the working group = will > consider a mechanism for verification of the originator during session > establishment in an environment with one or more non-SIP hops, most > likely requiring an out-of-band authorization mechanism. However, the > in-band and the out-of-band mechanisms should share as much in common = as > possible, especially the credentials. The in-band mechanism must be = sent > to the IESG for approval and publication prior to the out-of-band > mechanism. >=20 > Expansion of the authorization mechanism to identities using the > user@domain form are deferred since the main focus of the working = group > is to develop a solution for telephone numbers. >=20 > The working group will coordinate with the Security Area on credential > management. >=20 > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. >=20 > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and = this > working group will not propose changes to these standards. In order = to > support anonymity, the working group will provide a solution in which = the > called party receives an indication that the source telephone number = is > unavailable. This working group, to the extent feasible, will specify > privacy-friendly mechanisms that do not reveal any more information to > user agents or third parties than a call that does not make use of = secure > telephone identification mechanisms. >=20 > Input to working group discussions shall include: >=20 > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] >=20 > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] >=20 > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] >=20 > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] >=20 > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] >=20 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situations that motivate work on secure telephone identity >=20 > - A threat model for the secure telephone identity mechanisms >=20 > - A privacy analysis of the secure telephone identity mechanisms >=20 > - A document describing the SIP in-band mechanism for telephone > number-based identities during call setup >=20 > - A document describing the credentials required to support > telephone number identity authentication >=20 > - A document describing the out-of-band mechanism for telephone > number-based identities during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_A91672EB-7A8B-4FDD-9404-329A459527AE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA5MjIzNzQ1WjAjBgkqhkiG9w0BCQQxFgQU IX2+E52zAgulqZCIii+wC6C2ZdIwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAeJdOUG+E0E5BvBSm2jAGvQRebd5m2zDbVZo9Cf+HYvdMQdcson9Q sah8S5WqJoAddm4MQFg+bDf+A7gD2kwqA2RsVTvdlB01qRmHUGrNgTIyCkJx/hJFe3pTeoIeLrSg mcFJgRAOUDb8jgiDeSA0mT0LwEiIt8fV+L72mErWNBMXMB9TN9nLBi33H5ztsD5InGG5EsGQqCnV 1wfegDka7hpX6Xi4ULiLe02HaEIc3KflTETbVaaIMVLh5Onmwh23t31Nmy7LqCSQNk7iDRjcBWr9 PQppEOktjEHJ9Q/SY+CGx1BjSYvaKRJeWLBPtMnyEf8m/Qx3I6HxGQ0qP3d6xwAAAAAAAA== --Apple-Mail=_A91672EB-7A8B-4FDD-9404-329A459527AE-- From ekr@rtfm.com Fri Aug 9 17:09:18 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E23221E808C for ; Fri, 9 Aug 2013 17:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2prfsu7AVkY for ; Fri, 9 Aug 2013 17:09:04 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 971C011E80FE for ; Fri, 9 Aug 2013 17:02:55 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so2692571qeb.15 for ; Fri, 09 Aug 2013 17:02:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yYMEhJrytFWnR4exaeiudJTOrXvvOs/dmw5o+3O/7oY=; b=W0scUJNBcvCleDM0PGrMztseDuqX2pft5jofM/Ybe9f4A9ja4l8evIS6PMgta4itJ/ 2j/jt1R38mwAZpTIIAOAYjZvuPQuF2OEVWDysmyepoWDsrDpgq3P7JejrQMVAULLvwZG SCJX+qRTGkTFbXNeobvcZ2MFts5oFKL/1sJWwBEGDo/AvmElIP9A7pOmUbrBqpNf2RIF VAp/mjvQ9Nhz6wlDUhAzaxwaqEc5DBzmyDBbFxeRrf0+ZzxT83UP4ufqE3+AOcHUc9Lp xJATbMmq2cilB2683gUYwDgl+9flhdFcneToHxioLZ2dndl9fxGeBRzrXYpWesA76bNI beeg== X-Gm-Message-State: ALoCoQm9/S+oEyCPENqQ6tl+AM6XZpdWo0TzsxSiXSRgEG8IKZX/65IecxPHqgtCVJDgSh0pOvvl X-Received: by 10.224.73.200 with SMTP id r8mr12759435qaj.90.1376092974967; Fri, 09 Aug 2013 17:02:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Fri, 9 Aug 2013 17:02:14 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: <691C8CC2-B20F-4684-A6E4-52D4D0F00657@standardstrack.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> <691C8CC2-B20F-4684-A6E4-52D4D0F00657@standardstrack.com> From: Eric Rescorla Date: Fri, 9 Aug 2013 17:02:14 -0700 Message-ID: To: Eric Burger Content-Type: multipart/alternative; boundary=001a11c3e420f3aeda04e38c9c05 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:09:19 -0000 --001a11c3e420f3aeda04e38c9c05 Content-Type: text/plain; charset=ISO-8859-1 I think you're massively overrating the importance of the existence of an RFC on this topic. However, I agree we should emphasize the importance of an anonymous option. -Ekr On Fri, Aug 9, 2013 at 3:18 PM, Eric Burger wrote: > It is one thing for the regulators to say "be bad." It is another thing > for the regulators to say "do bad things because the IETF says it is good." > > On Aug 9, 2013, at 12:00 AM, Eric Rescorla wrote: > > > > > > > > > On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger > wrote: > > On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan > wrote: > > > On Aug 5, 2013, at 4:36 PM, Eric Burger > wrote: > > > I agree we are not looking at a national security private network > analysis. However, we are talking about the potential end of any privacy or > anonymity for ANY Internet application, more especially Internet multimedia > application. > > > > > > How so? Obviously we could theoretically create some mechanism that > took all call information from/to everyone and posted it to wikileaks or > > > whatever, but I don't think we're that stupid. (nor do I think it > would get published by the IETF, nor would anyone use it if we did) > > > > > > No one is proposing, for example, that anonymous calls no longer > remain anonymous. Nor that one can't make anonymous calls. > > > > Actually, we are. We are talking about "official" calling. Otherwise, we > would have p2psip and there would not be regulators in the middle. It would > not be hard to imaging regulators banning anonymous calling, as the bad > guys all use anonymous calling and grandpa still answers the call and hands > over his life savings to the nice lady on the phone. > > > > I'm not following this argument at all. The regulators could presumably > > require this now. How does STIR change the situation? > > > > -Ekr > > > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --001a11c3e420f3aeda04e38c9c05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think you're massively overrating the importance of = the existence of
an RFC on this topic. However, I agree we should empha= size the
importance of an anonymous option.

-Ekr



On Fri, Aug 9, 2013 at 3:18 PM, Eric Burger <eburger@standardstrack.com> wrote:
It is one thing for the regulators to say &q= uot;be bad." It is another thing for the regulators to say "do ba= d things because the IETF says it is good."

On Aug 9, 2013, at 12:00 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
>
> On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger <eburger@standardstrack.com> wrote:
> On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:
> > On Aug 5, 2013, at 4:36 PM, Eric Burger <eburger@standardstrack.com> wrote:
> > I agree we are not looking at a national security private network= analysis. However, we are talking about the potential end of any privacy o= r anonymity for ANY Internet application, more especially Internet multimed= ia application.
> >
> > How so? =A0Obviously we could theoretically create some mechanism= that took all call information from/to everyone and posted it to wikileaks= or
> > whatever, but I don't think we're that stupid. (nor do I = think it would get published by the IETF, nor would anyone use it if we did= )
> >
> > No one is proposing, for example, that anonymous calls no longer = remain anonymous. =A0Nor that one can't make anonymous calls.
>
> Actually, we are. We are talking about "official" calling. O= therwise, we would have p2psip and there would not be regulators in the mid= dle. It would not be hard to imaging regulators banning anonymous calling, = as the bad guys all use anonymous calling and grandpa still answers the cal= l and hands over his life savings to the nice lady on the phone.
>
> I'm not following this argument at all. The regulators could presu= mably
> require this now. How does STIR change the situation?
>
> -Ekr
>
>


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir


--001a11c3e420f3aeda04e38c9c05-- From hadriel.kaplan@oracle.com Fri Aug 9 17:43:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD8921F9C20 for ; Fri, 9 Aug 2013 17:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGMgr-o6geOW for ; Fri, 9 Aug 2013 17:43:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8821F0D84 for ; Fri, 9 Aug 2013 17:36:57 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7A0at8P018499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Aug 2013 00:36:55 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7A0arug004983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Aug 2013 00:36:54 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7A0arM6019325; Sat, 10 Aug 2013 00:36:53 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 17:36:53 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <691C8CC2-B20F-4684-A6E4-52D4D0F00657@standardstrack.com> Date: Fri, 9 Aug 2013 20:36:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <59F6D845-F6E1-4CAE-8C20-4BC7594CA66C@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> <691C8CC2-B20F-4684-A6E4-52D4D0F00657@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:43:51 -0000 On Aug 9, 2013, at 6:18 PM, Eric Burger = wrote: > It is one thing for the regulators to say "be bad." It is another = thing for the regulators to say "do bad things because the IETF says it = is good." Wow, that is an impressive spin. :) Last time I checked, the regulators didn't exactly consult the IETF on = policy decisions. We don't pay nearly enough lobbyists. I mean I'm = sure there're quite a few MUST and MUST NOT statements the IETF would = like to send their way on various topics, but methinks it would fall on = deaf ears. Regardless, how do you propose we solve this dilemma? Add a "MUST NOT = block anonymous requests" type statement in the RFCs? I'm cool with = doing that, fwiw. I think it would be ignored though, if regulators = decided to block them anyway. -hadriel From richard@shockey.us Mon Aug 12 09:59:27 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF9721F9EB8 for ; Mon, 12 Aug 2013 09:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.831 X-Spam-Level: X-Spam-Status: No, score=-100.831 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oDyhKbSnK31 for ; Mon, 12 Aug 2013 09:59:15 -0700 (PDT) Received: from oproxy14-pub.mail.unifiedlayer.com (oproxy14-pub.mail.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id ACC3221F8265 for ; Mon, 12 Aug 2013 09:38:53 -0700 (PDT) Received: (qmail 10012 invoked by uid 0); 12 Aug 2013 16:38:47 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 12 Aug 2013 16:38:46 -0000 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:Date:Subject:In-Reply-To:References:Cc:To:From; bh=+9yhx9bdzVrCVSaqYGayL/FSQJOaquYwQ5uRwbC0eRo=; b=QstKCp3IHNb4hxpK2a4IHNq66OnJIrIyDmiE6QGFS673LTVp68Y0E812+pLcuVCgyZUYiYGdOem9xSKEcUX9bJ0BGSJDPMh/5IvZsVidyxdnl9h7tJJ2XFGVfdB1J/S1; Received: from [71.114.100.16] (port=53727 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V8v8o-0005FW-1Q; Mon, 12 Aug 2013 10:38:46 -0600 From: "Richard Shockey" To: "'Eric Rescorla'" , "'Eric Burger'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> <691C8CC2-B20F-4684-A6E4-52D4D0F00657@standardstrack.com> In-Reply-To: Date: Mon, 12 Aug 2013 12:38:42 -0400 Message-ID: <00d201ce977a$68e44e00$3aacea00$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01CE9758.E1D434A0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAmNFLYoCnpukhgEvNu42AjGYGeoCHZbkzQDjeLtPAxu1ZRyYOHQKIA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 16:59:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D3_01CE9758.E1D434A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How do you define anonymous calling? What the network has to see to route the call or what is displayed on the User Agent? From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, August 09, 2013 8:02 PM To: Eric Burger Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I think you're massively overrating the importance of the existence of an RFC on this topic. However, I agree we should emphasize the importance of an anonymous option. -Ekr On Fri, Aug 9, 2013 at 3:18 PM, Eric Burger > wrote: It is one thing for the regulators to say "be bad." It is another thing for the regulators to say "do bad things because the IETF says it is good." On Aug 9, 2013, at 12:00 AM, Eric Rescorla > wrote: > > > > On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger > wrote: > On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan > wrote: > > On Aug 5, 2013, at 4:36 PM, Eric Burger > wrote: > > I agree we are not looking at a national security private network analysis. However, we are talking about the potential end of any privacy or anonymity for ANY Internet application, more especially Internet multimedia application. > > > > How so? Obviously we could theoretically create some mechanism that took all call information from/to everyone and posted it to wikileaks or > > whatever, but I don't think we're that stupid. (nor do I think it would get published by the IETF, nor would anyone use it if we did) > > > > No one is proposing, for example, that anonymous calls no longer remain anonymous. Nor that one can't make anonymous calls. > > Actually, we are. We are talking about "official" calling. Otherwise, we would have p2psip and there would not be regulators in the middle. It would not be hard to imaging regulators banning anonymous calling, as the bad guys all use anonymous calling and grandpa still answers the call and hands over his life savings to the nice lady on the phone. > > I'm not following this argument at all. The regulators could presumably > require this now. How does STIR change the situation? > > -Ekr > > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00D3_01CE9758.E1D434A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How do you define anonymous calling?

 

What the network has to see to route the call or what is displayed on = the User Agent?

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Eric Rescorla
Sent: Friday, August 09, 2013 8:02 = PM
To: Eric Burger
Cc: = stir@ietf.org
Subject: Re: [stir] Early Homework (was Re: = Moving from BOF to Charter)

 

I think = you're massively overrating the importance of the existence = of

an RFC on this topic. = However, I agree we should emphasize the

importance of an anonymous = option.

 

-Ekr

 

 

On Fri, Aug 9, 2013 at 3:18 PM, Eric Burger <eburger@standardstrack.com> = wrote:

It is one = thing for the regulators to say "be bad." It is another thing = for the regulators to say "do bad things because the IETF says it = is good."


On Aug 9, 2013, at 12:00 AM, Eric = Rescorla <ekr@rtfm.com> = wrote:

>
>
>
> On Thu, Aug 8, 2013 at 4:54 = PM, Eric Burger <eburger@standardstrack.com= > wrote:
> On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com&g= t; wrote:
> > On Aug 5, 2013, at 4:36 PM, Eric Burger <eburger@standardstrack.com= > wrote:
> > I agree we are not looking at a national = security private network analysis. However, we are talking about the = potential end of any privacy or anonymity for ANY Internet application, = more especially Internet multimedia application.
> >
> = > How so?  Obviously we could theoretically create some = mechanism that took all call information from/to everyone and posted it = to wikileaks or
> > whatever, but I don't think we're that = stupid. (nor do I think it would get published by the IETF, nor would = anyone use it if we did)
> >
> > No one is proposing, = for example, that anonymous calls no longer remain anonymous.  Nor = that one can't make anonymous calls.
>
> Actually, we are. = We are talking about "official" calling. Otherwise, we would = have p2psip and there would not be regulators in the middle. It would = not be hard to imaging regulators banning anonymous calling, as the bad = guys all use anonymous calling and grandpa still answers the call and = hands over his life savings to the nice lady on the = phone.
>
> I'm not following this argument at all. The = regulators could presumably
> require this now. How does STIR = change the situation?
>
> = -Ekr
>
>


______________________________________= _________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 

------=_NextPart_000_00D3_01CE9758.E1D434A0-- From ekr@rtfm.com Mon Aug 12 10:11:17 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B1721F9DAB for ; Mon, 12 Aug 2013 10:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbqbs9RNRyUS for ; Mon, 12 Aug 2013 10:11:09 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id AF48B21F99F3 for ; Mon, 12 Aug 2013 09:54:53 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id x7so3734896qeu.18 for ; Mon, 12 Aug 2013 09:54:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=e+8Hn1oDMGdZ384VuFxalyMwaCyOZEoc2e7V9FTY9To=; b=mDKzTZlZoEG18ktyS9PA6JAxGoi6hjtq5UJhKcT7NANIpfXJPGkx5IuQJt6MtUsOaf c5epo/S96EW+W3PC2LIZeSBWYOLUwK/ssVQLr4g+2fnD0kQ9IUweG/BRFWRdo5i6Cq8H DZ2SwrJGfOkcd5obNSxqoYPz/2Vm+kY4r3ZHRMz9wGn7zeTaJpH0328/3w6Bj8Wu3iS/ oHLcEqytop3PTAfJONXZvJh9DWwjgaR64SrNKAeCkMPAPdFJZKwgcDRmY59zcC9y02Ie 5jgZDcPMFPSWn0HbMu2oNBBaUIq1IfQsvU8yA739+9jXUrSbvybWgMyfDWSc4YuN9iap ncdw== X-Gm-Message-State: ALoCoQnbKjhQz5S8JaS9xRayKAQ7nVWp9ZEy6AJLUySkBsKrreKypYyjZoNXaZZi2UUSPaePN+o1 X-Received: by 10.49.25.167 with SMTP id d7mr25355qeg.35.1376326484244; Mon, 12 Aug 2013 09:54:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Mon, 12 Aug 2013 09:54:04 -0700 (PDT) X-Originating-IP: [2620:101:8003:200:64a8:1ad8:b04c:229] In-Reply-To: <00d201ce977a$68e44e00$3aacea00$@shockey.us> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> <691C8CC2-B20F-4684-A6E4-52D4D0F00657@standardstrack.com> <00d201ce977a$68e44e00$3aacea00$@shockey.us> From: Eric Rescorla Date: Mon, 12 Aug 2013 09:54:04 -0700 Message-ID: To: Richard Shockey Content-Type: multipart/alternative; boundary=047d7b6d9fc8304b0904e3c2fb67 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:11:18 -0000 --047d7b6d9fc8304b0904e3c2fb67 Content-Type: text/plain; charset=ISO-8859-1 What the ordinary callee sees. I.e., the properties I take the current system to have. -Ekr On Mon, Aug 12, 2013 at 9:38 AM, Richard Shockey wrote: > How do you define anonymous calling? **** > > ** ** > > What the network has to see to route the call or what is displayed on the > User Agent?**** > > ** ** > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf > Of *Eric Rescorla > *Sent:* Friday, August 09, 2013 8:02 PM > > *To:* Eric Burger > *Cc:* stir@ietf.org > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to Charter)* > *** > > ** ** > > I think you're massively overrating the importance of the existence of**** > > an RFC on this topic. However, I agree we should emphasize the**** > > importance of an anonymous option.**** > > ** ** > > -Ekr**** > > ** ** > > ** ** > > On Fri, Aug 9, 2013 at 3:18 PM, Eric Burger > wrote:**** > > It is one thing for the regulators to say "be bad." It is another thing > for the regulators to say "do bad things because the IETF says it is good." > **** > > > On Aug 9, 2013, at 12:00 AM, Eric Rescorla wrote: > > > > > > > > > On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger > wrote: > > On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan > wrote: > > > On Aug 5, 2013, at 4:36 PM, Eric Burger > wrote: > > > I agree we are not looking at a national security private network > analysis. However, we are talking about the potential end of any privacy or > anonymity for ANY Internet application, more especially Internet multimedia > application. > > > > > > How so? Obviously we could theoretically create some mechanism that > took all call information from/to everyone and posted it to wikileaks or > > > whatever, but I don't think we're that stupid. (nor do I think it > would get published by the IETF, nor would anyone use it if we did) > > > > > > No one is proposing, for example, that anonymous calls no longer > remain anonymous. Nor that one can't make anonymous calls. > > > > Actually, we are. We are talking about "official" calling. Otherwise, we > would have p2psip and there would not be regulators in the middle. It would > not be hard to imaging regulators banning anonymous calling, as the bad > guys all use anonymous calling and grandpa still answers the call and hands > over his life savings to the nice lady on the phone. > > > > I'm not following this argument at all. The regulators could presumably > > require this now. How does STIR change the situation? > > > > -Ekr > > > >**** > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir**** > > ** ** > --047d7b6d9fc8304b0904e3c2fb67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What the ordinary callee sees. I.e., the properties I take= the current system to
have.

-Ekr


= On Mon, Aug 12, 2013 at 9:38 AM, Richard Shockey <richard@shockey.us&= gt; wrote:

How do you de= fine anonymous calling?

=A0<= /p>

What the network has t= o see to route the call or what is displayed on the User Agent?

=A0<= /p>

From: stir-bounces@ietf.o= rg [mailto:s= tir-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, August 09, 2013 8:02 PM

To: Eric Burger
Cc: stir@ietf.org
Subject: Re: [stir] Early Homewo= rk (was Re: Moving from BOF to Charter)

=A0

I think you're massively overrating the importance of the existence= of

an = RFC on this topic. However, I agree we should emphasize the

importance of an anonymous option.=

=A0

-Ekr

=A0

=A0

On Fri, Au= g 9, 2013 at 3:18 PM, Eric Burger <eburger@standardstrack.com> wrote:=

= It is one thing for the regulators to say "be bad." It is another= thing for the regulators to say "do bad things because the IETF says = it is good."


On Aug = 9, 2013, at 12:00 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
>
&= gt; On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger <eburger@standardstrack.com>= wrote:
> On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com> w= rote:
> > On Aug 5, 2013, at 4:36 PM, Eric Burger <eburger@standardstrack.= com> wrote:
> > I agree we are not looking at a national security private network= analysis. However, we are talking about the potential end of any privacy o= r anonymity for ANY Internet application, more especially Internet multimed= ia application.
> >
> > How so? =A0Obviously we could theoretically create s= ome mechanism that took all call information from/to everyone and posted it= to wikileaks or
> > whatever, but I don't think we're tha= t stupid. (nor do I think it would get published by the IETF, nor would any= one use it if we did)
> >
> > No one is proposing, for example, that anonymous cal= ls no longer remain anonymous. =A0Nor that one can't make anonymous cal= ls.
>
> Actually, we are. We are talking about "official&q= uot; calling. Otherwise, we would have p2psip and there would not be regula= tors in the middle. It would not be hard to imaging regulators banning anon= ymous calling, as the bad guys all use anonymous calling and grandpa still = answers the call and hands over his life savings to the nice lady on the ph= one.
>
> I'm not following this argument at all. The regulators cou= ld presumably
> require this now. How does STIR change the situation?=
>
> -Ekr
>
>


_______________________________________________
stir mailing liststir@ietf.org
http= s://www.ietf.org/mailman/listinfo/stir

=A0

=

--047d7b6d9fc8304b0904e3c2fb67-- From hadriel.kaplan@oracle.com Mon Aug 12 11:53:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCCE21E804B for ; Mon, 12 Aug 2013 11:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhIC7C1Sa-Rt for ; Mon, 12 Aug 2013 11:53:50 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 42F9521F9CC6 for ; Mon, 12 Aug 2013 11:53:47 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7CIrXvq030236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Aug 2013 18:53:34 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7CIrSSf013774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Aug 2013 18:53:31 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7CIrSQV025272; Mon, 12 Aug 2013 18:53:28 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Aug 2013 11:53:28 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51FA0753.6020600@bbn.com> Date: Mon, 12 Aug 2013 14:53:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org Mail List" , Dave Crocker Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 18:53:58 -0000 With regards to a threat document, I've been writing up one for STIR and = have been shamelessly copying from the BGP Path Security one cited in = the email below. I notice that the BGP one covers attacks against each and every actor in = the system, including routers themselves; and many forms of attack. = Were all the threats/attacks in the draft ones the SIDR WG was concerned = about, or they were all listed just to be comprehensive? In other = words, should a STIR threat doc cover every possible threat we can come = up with, or only the ones we think are relevant to STIR? For example, the BGP one included various MITM attacks, which we don't = seem as concerned with for STIR - should the doc cover all of those in = detail as well, or just say "this is not considered relevant for STIR"? -hadriel On Aug 1, 2013, at 2:59 AM, Stephen Kent wrote: > Dave, >=20 > I refer you to the BGPSEC threat doc = (draft-ietf-sidr-bgpsec-threats-05), which is now > in the hands of the RTG ADs, as an example of what I have in mind. It = addresses a > fairly complex, global system, so I would not expect an analogous doc = for STIR > to be any longer. >=20 > Steve >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Mon Aug 12 12:04:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE0921F9CAE for ; Mon, 12 Aug 2013 12:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW33KkRXDASL for ; Mon, 12 Aug 2013 12:04:15 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0593221F9C9A for ; Mon, 12 Aug 2013 12:04:15 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 12 Aug 2013 12:04:12 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "kent@bbn.com" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOjgt3HpeE9YPMkUaRYUJB0cUb+pmAYpmAgBIRHAD//41pEA== Date: Mon, 12 Aug 2013 19:04:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC270C8@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.33] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02BB_01CE976D.33809FA0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "dhc@dcrocker.net" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:04:19 -0000 ------=_NextPart_000_02BB_01CE976D.33809FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit May be best to briefly describe what the threat is, what are mitigating factors, and why STIR chose not to focus on that. At least then readers know it was conscious decision and not an omission. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, August 12, 2013 2:53 PM To: Stephen Kent Cc: stir@ietf.org Mail List; Dave Crocker Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) With regards to a threat document, I've been writing up one for STIR and have been shamelessly copying from the BGP Path Security one cited in the email below. I notice that the BGP one covers attacks against each and every actor in the system, including routers themselves; and many forms of attack. Were all the threats/attacks in the draft ones the SIDR WG was concerned about, or they were all listed just to be comprehensive? In other words, should a STIR threat doc cover every possible threat we can come up with, or only the ones we think are relevant to STIR? For example, the BGP one included various MITM attacks, which we don't seem as concerned with for STIR - should the doc cover all of those in detail as well, or just say "this is not considered relevant for STIR"? -hadriel On Aug 1, 2013, at 2:59 AM, Stephen Kent wrote: > Dave, > > I refer you to the BGPSEC threat doc > (draft-ietf-sidr-bgpsec-threats-05), which is now in the hands of the > RTG ADs, as an example of what I have in mind. It addresses a fairly > complex, global system, so I would not expect an analogous doc for STIR to be any longer. > > Steve > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_02BB_01CE976D.33809FA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx MjE5MDQxMVowIwYJKoZIhvcNAQkEMRYEFB+DLArOhk0bvetoxIqXpZSj63voMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAC18wyOw2At7o07w9RMbcWw6rNWhKUs/f9x5v3HcR f30vGxrO+vSgqKOfkVHFn999F8OQ/pNiJOQvLoZZPriPb/3CkL+ZCr4VzOvjmXVTNeewN8Qy/neB 7cgBP7Pv0hKIhWtaxgWiTuwXWneEdK/RzrzZcXKzH9n+I+wC94iG21hfG+xhiZh0lPdrwhcpX4wx 7Kl123gqkYIiSbuzJiRhcxHtWe3l5FgUDXcwml0LGvXsIBa3SfG1n9isi0BZ/IQWVgHC5DhL3A2t Pz1F4b2jsks5Pjsp5cKrew+H2ISyCakpar5Qggu6TBNGufGKOatr8hRpuUjPspSOAmn2s8sb8AAA AAAAAA== ------=_NextPart_000_02BB_01CE976D.33809FA0-- From jon.peterson@neustar.biz Mon Aug 12 13:20:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F6521F9E6D for ; Mon, 12 Aug 2013 13:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.145 X-Spam-Level: X-Spam-Status: No, score=-106.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PAOEmkiMkZ0 for ; Mon, 12 Aug 2013 13:20:36 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 21F8521F9EEB for ; Mon, 12 Aug 2013 13:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1376338805; x=1691698523; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=7Rq58bjKvF pVRaLk+0Q5+qzvaeoJ4hK7ITumlkIFjVc=; b=cnRVZ/36yKBpbOlOktRqu+Zmog /R3yn+Omw8+J2UXcUFK3aNJ8NHWNviABjZkKoTcOuCJTK78Uo/GDf50M24NA== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.23783088; Mon, 12 Aug 2013 16:20:03 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.190]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 12 Aug 2013 16:20:18 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Stephen Kent Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOjgt2bbNz4o/060a24iT0QVXSrpmAME6AgBIRHQD//6LpgA== Date: Mon, 12 Aug 2013 20:20:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.145] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: YUqsD0xaYhQaFHHVx85mOw== Content-Type: text/plain; charset="us-ascii" Content-ID: <9233AB5A9EC610439E789CFE9831A30F@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org Mail List" , Dave Crocker Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 20:20:41 -0000 There is a relatively lengthy section on threats already in the secure-origin-ps-01 document (5.7) which lays out at least the fundamentals (actors, scenarios, etc), without going into the attack surface created by the solutions. Going in to the last meeting, my understanding was we wanted this text to be in the problem statement document; now that it's a separate deliverable in the proposed charter, that text probably doesn't belong in the problem statement document anymore. Jon Peterson Neustar, Inc. On 8/12/13 11:53 AM, "Hadriel Kaplan" wrote: > >With regards to a threat document, I've been writing up one for STIR and >have been shamelessly copying from the BGP Path Security one cited in the >email below. > >I notice that the BGP one covers attacks against each and every actor in >the system, including routers themselves; and many forms of attack. Were >all the threats/attacks in the draft ones the SIDR WG was concerned >about, or they were all listed just to be comprehensive? In other words, >should a STIR threat doc cover every possible threat we can come up with, >or only the ones we think are relevant to STIR? > >For example, the BGP one included various MITM attacks, which we don't >seem as concerned with for STIR - should the doc cover all of those in >detail as well, or just say "this is not considered relevant for STIR"? > >-hadriel > > >On Aug 1, 2013, at 2:59 AM, Stephen Kent wrote: > >> Dave, >>=20 >> I refer you to the BGPSEC threat doc >>(draft-ietf-sidr-bgpsec-threats-05), which is now >> in the hands of the RTG ADs, as an example of what I have in mind. It >>addresses a >> fairly complex, global system, so I would not expect an analogous doc >>for STIR >> to be any longer. >>=20 >> Steve >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Mon Aug 12 14:17:13 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42BD21F9EED for ; Mon, 12 Aug 2013 14:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiUK8oiIqWhc for ; Mon, 12 Aug 2013 14:17:09 -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 5C7D121F9F9A for ; Mon, 12 Aug 2013 14:17:08 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' , Eric Burger Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOjgt+dEEP/VWSH0ySyr6H5u4hu5mHXfEAgADukQCAA/+cAIAAOpWAgAWcpWA= Date: Mon, 12 Aug 2013 21:17:05 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <402B47C6-4098-448A-9F88-0E45DAE507C8@oracle.com> <4DE7674D-761F-4651-8E2B-4F5B4183294C@standardstrack.com> <6A868569-552F-425B-A1AB-60149E17DFC6@oracle.com> In-Reply-To: <6A868569-552F-425B-A1AB-60149E17DFC6@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 21:17:13 -0000 Apologies if I missed this discussion among the 300+ STIR messages, but I t= hink it would help if we distinguished two kinds of anonymous calls: * truly anonymous, i.e., none of the carriers knows the identity of the cal= ler * callerID suppressed calls, i.e., the carriers do. Most anonymous calls today fall into the second category, i.e., if you are = stupid enough to call in a threat using *67 callerID suppression from your = home phone, you will likely have the doorbell ring pretty quickly. Payphone= s and cash-paid prepay phones offer an approximation of the first kind of a= nonymity. Even the first kind aren't really fully anonymous - with a subpoena and ass= uming a domestic or friendly-foreign caller, you can find out who made the = call (or at least which payphone), by tracing the call through its path bas= ed only on time and destination numbers. Happens all the time (and that's h= ow domestic boiler room operators are caught, among other ways). Thus, I think it would help the discussion to be very precise what kind of = anonymity is being preserved or threatened. In many cases, such as 1-800 ti= p lines, this is really more like a promise not to trace the call, not a te= chnical, TOR-like, feature, or anonymity towards the callee. CallerID suppression does not appear to be impacted by signing; stating thi= s as a goal, however, is useful. You could argue that if callees knew that = nuisance and other illegal callers could be identified if they crossed the = threshold into illegality, they'd be more likely to be accepted. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Thursday, August 08, 2013 11:24 PM To: Eric Burger Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On Aug 8, 2013, at 7:54 PM, Eric Burger wrote: > On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan wr= ote: >> No one is proposing, for example, that anonymous calls no longer remain = anonymous. Nor that one can't make anonymous calls. >=20 > Actually, we are. We are talking about "official" calling. Otherwise, we = would have p2psip and there would not be regulators in the middle. You lost me. I have no idea what p2psip has to do with anything. If you t= hink p2psip failed because it allows anonymous calls, you are waaay off. = You must mean something else, but I'm not getting it.(?) > It would not be hard to imaging regulators banning anonymous calling, as = the bad guys all use anonymous calling and grandpa still answers the call a= nd hands over his life savings to the nice lady on the phone. It's theoretically possible that such a thing could happen. I think it's u= nlikely for regulators to do it, but people today are already ignoring anon= ymous calls so it might be more of a result that no one ever answers them, = rather than regulatory mandate that carriers block them. So what? Are we = supposed to make people accept anonymous communication requests if they don= 't want to? Should we be encouraging spoofing in order to give attackers a= n incentive to not anonymize their calls? Should we be just constantly ran= domizing source numbers for all calls in the future, in order to protect th= e rights of those who don't want their source number known? Should we just= make all future calls be anonymous? What's your proposed solution to such= a dilemma? In some ways, getting to a stage of deployment where all bad guys use anony= mous numbers is a *good thing*. The fact is most users are already conditi= oned to distrust anonymous calls, meaning the bad guys will have a lower su= ccess rate, which means the fraud folks have an easier time tracking the ba= d guys down. Ultimately, you *should* distrust anonymous calls - you reall= y do need to be more cautious, less trusting, etc. No? > After that, what stops the regulators from congratulating the IETF on doi= ng such a good job on phone calls to extend it to email? And then to IM? An= d then to TOR? Ah yes, the old slippery-slope argument. I can play that game too. :) Using that logic: if we decide to not work on STIR because we're worried th= at providing a mechanism for source identity verification means governments= will decide to prevent anonymous sources... then we should shut down a who= le bunch of stuff in the IETF, deprecate a crap-load of RFCs, and retire to= the beach. You could start with shutting down SCIM, REPUTE, SAVI, KITTEN,= DANE, OAUTH, and probably a few others (you can never be too careful!). A= nd of course immediately deprecate DKIM, rfc4474, Mutual-TLS, any digest au= th mechanism in any protocol, etc. I mean if we provide a means of authent= icating users, then governments might not allow anonymous users, so we need= to remove the mechanisms from our specs. Right? At the end of the day we're the IETF, not ICANN or a government body. They= debate politics and policy. We solve technical problems. How are we supp= osed to get anything accomplished, if we have to worry about governments ab= using their power and potentially taking advantage of success of our mechan= isms? -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Mon Aug 12 14:22:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD1021E804B for ; Mon, 12 Aug 2013 14:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKdvxQrRZf-9 for ; Mon, 12 Aug 2013 14:22:53 -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 22FC321F9F9D for ; Mon, 12 Aug 2013 14:22:51 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Russ Housley' , Brian Rosen Thread-Topic: [stir] Moving from BOF to Charter Thread-Index: AQHOjfnzqKBJtlavVEST8ooMdGvZdpmHT2kAgAFpOICAAD9DgIAABQWAgAMDDwCAABjBAIABIAuAgATvDZA= Date: Mon, 12 Aug 2013 21:22:47 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lynch@isoc.org" , IETF STIR Mail List , Stephen Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 21:22:59 -0000 Looks good to me. It is not clear, however, whether " A called party will r= eceive an indication that the source telephone number is unavailable in ord= er to provide anonymity. " refers to a description of the status quo or a c= harter goal. This sounds like the existing SIP mechanism to me. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Friday, August 09, 2013 10:01 AM To: Brian Rosen Cc: lynch@isoc.org; IETF STIR Mail List; Stephen Kent Subject: Re: [stir] Moving from BOF to Charter Below is the current charter text. Is it ready for the IESG? Russ > Thanks. >=20 > Is that it? Is everyone okay with the charter language now? Russ will p= ost a new complete version just to make sure, but can we send this to the I= ESG and ask for the work group? >=20 > Brian =3D =3D =3D =3D =3D =3D =3D =3D=20 Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir The STIR working group will specify mechanisms for the validation of source= telephone number for an incoming call. Since it has become fairly easy to= present an incorrect source telephone number, a growing set of problems ha= ve emerged over the last decade. As with email, the claimed source identit= y of a SIP request is not verified, permitting unauthorized use of the sour= ce identity as part of deceptive and coercive activities, such as robocalli= ng (bulk unsolicited commercial communications), vishing (voicemail hacking= , and impersonating banks) and swatting (impersonating callers to emergency= services to stimulate unwarranted large scale law enforcement deployments)= . In addition, use of an incorrect source telephone number facilitates wir= e fraud or lead to a return call at premium rates. This working group will= define mechanisms that verify the authorization of the calling party to us= e a particular telephone number. SIP is one of the main VoIP technologies used by parties that want to prese= nt an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communicat= ions, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen a= ny appreciable deployment. Several factors contributed to this lack of suc= cess, including: failure of the problem to be seen as critical at the time;= lack of any technical means of producing a proof of authority over telepho= ne numbers; misalignment of the mechanisms proposed by RFC 4474 with the co= mplex deployment environment that has emerged for SIP; lack of end-to-end S= IP session establishment; and inherent operational problems with a transiti= ve trust model. To make deployment of this solution more likely, considera= tion must be given to latency, real-time performance, computational overhea= d, and administrative overhead for the legitimate call source and all verif= iers. As its priority mechanism work item, the working group will specify a SIP h= eader-based mechanism to verify the originator of a SIP session is authoriz= ed to use the claimed source telephone number, where the session is establi= shed with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specifie= d by the working group, including any mappings that might be needed between= the SIP header fields and the canonical telephone number representation. = The working group will consider choices for protecting identity information= and credentials used, but will likely be based on a digital signature mech= anism that covers a set of information in the SIP header fields, and verifi= cation will employ a credential that contains the public key and is associa= ted with the one or more telephone numbers. In order to be authoritative, credentials used with this mechanism will be = derived from existing telephone number assignment and delegation models. T= hat is, when a telephone number or range of telephone numbers is delegated = to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone= number holder to further delegate and revoke use of a telephone number wit= hout compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will con= sider session establishment where there are one or more non-SIP hops, most = likely using an out-of-band mechanism. However, the in-band and the out-of= -band mechanisms should share as much in common as possible, especially the= credentials. The in-band mechanism must be sent to the IESG for approval = and publication prior to the out-of-band mechanism. Expansion of the authorization mechanism to identities using the user@domai= n form deferred since the main focus of the working group is to develop a s= olution for telephone numbers. The working group will coordinate with the Security Area on credential mana= gement. The working group will coordinate with other working groups in the RAI Area= regarding signaling through existing deployments. Authentication and authorization of identity is closely linked to privacy, = and these security features sometimes come at the cost of privacy. Anonymo= us calls are already defined in SIP standards, and this working group will = not propose changes to these standards. A called party will receive an ind= ication that the source telephone number is unavailable in order to provide= anonymity. This working group, to the extent feasible, will specify priva= cy-friendly mechanisms that do not reveal any more information to user agen= ts or third parties than a call that does not make use of secure telephone = identification mechanisms. Input to working group discussions shall include: - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks [RFC 3325] - Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) [RFC 4474] - Secure Call Origin Identification [draft-cooper-iab-secure-origin-00] - Secure Origin Identification: Problem Statement, Requirements, and Roadmap [draft-peterson-secure-origin-ps-00] - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-jennings-dispatch-rfc4474bis-00] The working group will deliver the following: - A problem statement detailing the deployment environment and situation that motivate work on secure telephone identity - A threat model for the secure telephone identity mechanisms - A privacy analysis of the secure telephone identity mechanisms - A mechanism document describing the SIP end-to-end with telephone number-based identities=20 - A document describing the credentials required to support telephone number identity authentication - A fallback mechanism to allow out-of-band identity establishment during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit threat model for Informational Nov 2013 Submit in-band mechanism for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Apr 2014 Submit Privacy analysis for Informational Jun 2014 Submit out-of-band mechanism for Proposed Standard _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Mon Aug 12 14:57:29 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2CD21F9FD7 for ; Mon, 12 Aug 2013 14:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3l-hx-aWNm7 for ; Mon, 12 Aug 2013 14:57:21 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id AEEF711E80D2 for ; Mon, 12 Aug 2013 14:57:21 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id wz12so7135864pbc.39 for ; Mon, 12 Aug 2013 14:57:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6Eow04vtJUHPXPNGDt8AvRkysE51jC6kidIO/WdT3Z4=; b=aPl8Od8lNwU4XcZ36uvn8kx5lUPBABmLgj22gur2Eg2gSZ6AUI9U2+iNJpMmNJkjij Os97WFygev95VHw0gVfVKGMG9y+qqqVtjigCcOjidjI5nteOfhsexWdZ1dQ/ZB0AwILJ vXxULbZRWwMX+ua1FQ62Uk3Fyofg74U3MZ2PFW+HuxYuPRd0tjtq2gkhgp3lk1rmlPGG dfSuiI0I7c1F5iahvKh//pi6lVOSIxpReQx6i9SFGRQZb2PRvNmbBW76bYEhX1C7qDwL G2DxzdoOE2sKn9I4XYEgWHEiIF9stVGIw8T3lq27+R79Glll/Bu5L8Yj3sP+yZeSk9SR btwQ== X-Gm-Message-State: ALoCoQmu/id5w+S033BylH0WNVmBxtUz9LJ2mHRgT2P24xg88RuVrkYnxx9gUK5pcVyRrPBGbfQM MIME-Version: 1.0 X-Received: by 10.66.192.132 with SMTP id hg4mr1128348pac.84.1376344640876; Mon, 12 Aug 2013 14:57:20 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Mon, 12 Aug 2013 14:57:20 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> Date: Mon, 12 Aug 2013 17:57:20 -0400 Message-ID: From: Brian Rosen To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=047d7bdc93ca68847504e3c735cf Cc: "lynch@isoc.org" , IETF STIR Mail List , Russ Housley , Stephen Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 21:57:31 -0000 --047d7bdc93ca68847504e3c735cf Content-Type: text/plain; charset=ISO-8859-1 It's supposed to be either of the two existing mechanisms (actual sending of anonymous From and suppresssion of callerid at the termination network). In either case, you get an indication in the signaling of what occurred. Brian On Monday, August 12, 2013, Henning Schulzrinne wrote: > Looks good to me. It is not clear, however, whether " A called party will > receive an indication that the source telephone number is unavailable in > order to provide anonymity. " refers to a description of the status quo or > a charter goal. This sounds like the existing SIP mechanism to me. > > Henning > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] > On Behalf Of Russ Housley > Sent: Friday, August 09, 2013 10:01 AM > To: Brian Rosen > Cc: lynch@isoc.org ; IETF STIR Mail List; Stephen Kent > Subject: Re: [stir] Moving from BOF to Charter > > Below is the current charter text. Is it ready for the IESG? > > Russ > > > Thanks. > > > > Is that it? Is everyone okay with the charter language now? Russ will > post a new complete version just to make sure, but can we send this to the > IESG and ask for the work group? > > > > Brian > > = = = = = = = = > > Name: Secure Telephone Identity Revisited (stir) > Area: RAI > > Chairs: TBD > Area Advisor: Richard Barnes > > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir > > The STIR working group will specify mechanisms for the validation of > source telephone number for an incoming call. Since it has become fairly > easy to present an incorrect source telephone number, a growing set of > problems have emerged over the last decade. As with email, the claimed > source identity of a SIP request is not verified, permitting unauthorized > use of the source identity as part of deceptive and coercive activities, > such as robocalling (bulk unsolicited commercial communications), vishing > (voicemail hacking, and impersonating banks) and swatting (impersonating > callers to emergency services to stimulate unwarranted large scale law > enforcement deployments). In addition, use of an incorrect source > telephone number facilitates wire fraud or lead to a return call at premium > rates. This working group will define mechanisms that verify the > authorization of the calling party to use a particular telephone number. > > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not seen > any appreciable deployment. Several factors contributed to this lack of > success, including: failure of the problem to be seen as critical at the > time; lack of any technical means of producing a proof of authority over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with > the complex deployment environment that has emerged for SIP; lack of > end-to-end SIP session establishment; and inherent operational problems > with a transitive trust model. To make deployment of this solution more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate call > source and all verifiers. > > As its priority mechanism work item, the working group will specify a SIP > header-based mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, where the session is > established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be needed > between the SIP header fields and the canonical telephone number > representation. The working group will consider choices for protecting > identity information and credentials used, but will likely be based on a > digital signature mechanism that covers a set of information in the SIP > header fields, and verification will employ a credential that contains the > public key and is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism will be > derived from existing telephone number assignment and delegation models. > That is, when a telephone number or range of telephone numbers is > delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a telephone > number without compromising the global delegation scheme. > > In addition to its priority mechanism work item, the working group will > consider session establishment where there are one or more non-SIP hops, > most likely using an out-of-band mechanism. However, the in-band and the > out-of-band mechanisms should share as much in common as possible, > especially the credentials. The in-band mechanism must be sent to the IESG > for approval and publication prior to the out-of-band mechanism. > > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is to > develop a solution for telephone numbers. > > The working group will coordinate with the Security Area on credential > management. > > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. > > Authentication and authori_______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7bdc93ca68847504e3c735cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's supposed to be either of the two existing mechanisms (actual sendi= ng of anonymous From and suppresssion of callerid at the termination networ= k). =A0In either case, you get an indication in the signaling of what occur= red.

Brian

On Monday, August 12, 2013, Hennin= g Schulzrinne wrote:
Looks good to me. I= t is not clear, however, whether " A called party will receive an indi= cation that the source telephone number is unavailable in order to provide = anonymity. " refers to a description of the status quo or a charter go= al. This sounds like the existing SIP mechanism to me.

Henning

-----Original Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, August 09, 2013 10:01 AM
To: Brian Rosen
Cc: lynch@isoc.org; IETF STIR Mail List; Stephen Kent
Subject: Re: [stir] Moving from BOF to Charter

Below is the current charter text. =A0Is it ready for the IESG?

Russ

> Thanks.
>
> Is that it? =A0Is everyone okay with the charter language now? =A0Russ= will post a new complete version just to make sure, but can we send this t= o the IESG and ask for the work group?
>
> Brian

=3D =3D =3D =3D =3D =3D =3D =3D

Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: Richard Barnes

Mailing list: stir@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

The STIR working group will specify mechanisms for the validation of source= telephone number for an incoming call. =A0Since it has become fairly easy = to present an incorrect source telephone number, a growing set of problems = have emerged over the last decade. =A0As with email, the claimed source ide= ntity of a SIP request is not verified, permitting unauthorized use of the = source identity as part of deceptive and coercive activities, such as roboc= alling (bulk unsolicited commercial communications), vishing (voicemail hac= king, and impersonating banks) and swatting (impersonating callers to emerg= ency services to stimulate unwarranted large scale law enforcement deployme= nts). =A0In addition, use of an incorrect source telephone number facilitat= es wire fraud or lead to a return call at premium rates. =A0This working gr= oup will define mechanisms that verify the authorization of the calling par= ty to use a particular telephone number.

SIP is one of the main VoIP technologies used by parties that want to prese= nt an incorrect origin, in this context an origin telephone number.
Several previous efforts have tried to secure the origins of SIP communicat= ions, including RFC 3325, RFC 4474, and the VIPR working group.
To date, however, true validation of the source of SIP calls has not seen a= ny appreciable deployment. =A0Several factors contributed to this lack of s= uccess, including: failure of the problem to be seen as critical at the tim= e; lack of any technical means of producing a proof of authority over telep= hone numbers; misalignment of the mechanisms proposed by RFC 4474 with the = complex deployment environment that has emerged for SIP; lack of end-to-end= SIP session establishment; and inherent operational problems with a transi= tive trust model. =A0To make deployment of this solution more likely, consi= deration must be given to latency, real-time performance, computational ove= rhead, and administrative overhead for the legitimate call source and all v= erifiers.

As its priority mechanism work item, the working group will specify a SIP h= eader-based mechanism to verify the originator of a SIP session is authoriz= ed to use the claimed source telephone number, where the session is establi= shed with SIP end to end. =A0This is called an in-band mechanism.
The mechanism will use a canonical telephone number representation specifie= d by the working group, including any mappings that might be needed between= the SIP header fields and the canonical telephone number representation. = =A0The working group will consider choices for protecting identity informat= ion and credentials used, but will likely be based on a digital signature m= echanism that covers a set of information in the SIP header fields, and ver= ification will employ a credential that contains the public key and is asso= ciated with the one or more telephone numbers.
In order to be authoritative, credentials used with this mechanism will be = derived from existing telephone number assignment and delegation models. = =A0That is, when a telephone number or range of telephone numbers is delega= ted to an entity, relevant credentials will be generated (or
modified) to reflect such delegation. =A0The mechanism must allow a telepho= ne number holder to further delegate and revoke use of a telephone number w= ithout compromising the global delegation scheme.

In addition to its priority mechanism work item, the working group will con= sider session establishment where there are one or more non-SIP hops, most = likely using an out-of-band mechanism. =A0However, the in-band and the out-= of-band mechanisms should share as much in common as possible, especially t= he credentials. =A0The in-band mechanism must be sent to the IESG for appro= val and publication prior to the out-of-band mechanism.

Expansion of the authorization mechanism to identities using the user@domai= n form deferred since the main focus of the working group is to develop a s= olution for telephone numbers.

The working group will coordinate with the Security Area on credential mana= gement.

The working group will coordinate with other working groups in the RAI Area= regarding signaling through existing deployments.

Authentication and authori_______________________________________________ stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir
--047d7bdc93ca68847504e3c735cf-- From Henning.Schulzrinne@fcc.gov Mon Aug 12 15:12:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70EE21E804C for ; Mon, 12 Aug 2013 15:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfvvxyZ91dXs for ; Mon, 12 Aug 2013 15:11: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 AECAB21E8055 for ; Mon, 12 Aug 2013 15:11:56 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' Thread-Topic: [stir] Moving from BOF to Charter Thread-Index: AQHOjfnzqKBJtlavVEST8ooMdGvZdpmHT2kAgAFpOICAAD9DgIAABQWAgAMDDwCAABjBAIABIAuAgATvDZCAAE0eAP//wIoQ Date: Mon, 12 Aug 2013 22:11:55 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FBA89BDp2pxmb13fccnetw_" MIME-Version: 1.0 Cc: "lynch@isoc.org" , IETF STIR Mail List , Russ Housley , Stephen Kent Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:12:03 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FBA89BDp2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks. My suggestion would be to make it clear that we're not looking to d= o any new work here (e.g., new privacy or CLID suppression headers), maybe = simply by grammatically tying the sentence to the previous one. From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 12, 2013 5:57 PM To: Henning Schulzrinne Cc: Russ Housley; lynch@isoc.org; IETF STIR Mail List; Stephen Kent Subject: Re: [stir] Moving from BOF to Charter It's supposed to be either of the two existing mechanisms (actual sending o= f anonymous From and suppresssion of callerid at the termination network). = In either case, you get an indication in the signaling of what occurred. Brian On Monday, August 12, 2013, Henning Schulzrinne wrote: Looks good to me. It is not clear, however, whether " A called party will r= eceive an indication that the source telephone number is unavailable in ord= er to provide anonymity. " refers to a description of the status quo or a c= harter goal. This sounds like the existing SIP mechanism to me. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley Sent: Friday, August 09, 2013 10:01 AM To: Brian Rosen Cc: lynch@isoc.org; IETF STIR Mail List; Stephen Kent Subject: Re: [stir] Moving from BOF to Charter Below is the current charter text. Is it ready for the IESG? Russ > Thanks. > > Is that it? Is everyone okay with the charter language now? Russ will p= ost a new complete version just to make sure, but can we send this to the I= ESG and ask for the work group? > > Brian =3D =3D =3D =3D =3D =3D =3D =3D Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir The STIR working group will specify mechanisms for the validation of source= telephone number for an incoming call. Since it has become fairly easy to= present an incorrect source telephone number, a growing set of problems ha= ve emerged over the last decade. As with email, the claimed source identit= y of a SIP request is not verified, permitting unauthorized use of the sour= ce identity as part of deceptive and coercive activities, such as robocalli= ng (bulk unsolicited commercial communications), vishing (voicemail hacking= , and impersonating banks) and swatting (impersonating callers to emergency= services to stimulate unwarranted large scale law enforcement deployments)= . In addition, use of an incorrect source telephone number facilitates wir= e fraud or lead to a return call at premium rates. This working group will= define mechanisms that verify the authorization of the calling party to us= e a particular telephone number. SIP is one of the main VoIP technologies used by parties that want to prese= nt an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communicat= ions, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen a= ny appreciable deployment. Several factors contributed to this lack of suc= cess, including: failure of the problem to be seen as critical at the time;= lack of any technical means of producing a proof of authority over telepho= ne numbers; misalignment of the mechanisms proposed by RFC 4474 with the co= mplex deployment environment that has emerged for SIP; lack of end-to-end S= IP session establishment; and inherent operational problems with a transiti= ve trust model. To make deployment of this solution more likely, considera= tion must be given to latency, real-time performance, computational overhea= d, and administrative overhead for the legitimate call source and all verif= iers. As its priority mechanism work item, the working group will specify a SIP h= eader-based mechanism to verify the originator of a SIP session is authoriz= ed to use the claimed source telephone number, where the session is establi= shed with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specifie= d by the working group, including any mappings that might be needed between= the SIP header fields and the canonical telephone number representation. = The working group will consider choices for protecting identity information= and credentials used, but will likely be based on a digital signature mech= anism that covers a set of information in the SIP header fields, and verifi= cation will employ a credential that contains the public key and is associa= ted with the one or more telephone numbers. In order to be authoritative, credentials used with this mechanism will be = derived from existing telephone number assignment and delegation models. T= hat is, when a telephone number or range of telephone numbers is delegated = to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone= number holder to further delegate and revoke use of a telephone number wit= hout compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will con= sider session establishment where there are one or more non-SIP hops, most = likely using an out-of-band mechanism. However, the in-band and the out-of= -band mechanisms should share as much in common as possible, especially the= credentials. The in-band mechanism must be sent to the IESG for approval = and publication prior to the out-of-band mechanism. Expansion of the authorization mechanism to identities using the user@domai= n form deferred since the main focus of the working group is to develop a s= olution for telephone numbers. The working group will coordinate with the Security Area on credential mana= gement. The working group will coordinate with other working groups in the RAI Area= regarding signaling through existing deployments. Authentication and authori_______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_E6A16181E5FD2F46B962315BB05962D01FBA89BDp2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks. My suggestion wou= ld be to make it clear that we’re not looking to do any new work here= (e.g., new privacy or CLID suppression headers), maybe simply by grammatically tying the sentence to the previous one.=

 <= /p>

From: Brian Ro= sen [mailto:br@brianrosen.net]
Sent: Monday, August 12, 2013 5:57 PM
To: Henning Schulzrinne
Cc: Russ Housley; lynch@isoc.org; IETF STIR Mail List; Stephen Kent<= br> Subject: Re: [stir] Moving from BOF to Charter

 

It's supposed to be either of the two existing mecha= nisms (actual sending of anonymous From and suppresssion of callerid at the= termination network).  In either case, you get an indication in the s= ignaling of what occurred.

 

Brian

On Monday, August 12, 2013, Henning Schulzrinne wrote:

Looks good to me. It is not clear, however, whether = " A called party will receive an indication that the source telephone = number is unavailable in order to provide anonymity. " refers to a des= cription of the status quo or a charter goal. This sounds like the existing SIP mechanism to me.

Henning

-----Original Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, August 09, 2013 10:01 AM
To: Brian Rosen
Cc: lynch@isoc.org; IETF STIR Mail List; Steph= en Kent
Subject: Re: [stir] Moving from BOF to Charter

Below is the current charter text.  Is it ready for the IESG?

Russ

> Thanks.
>
> Is that it?  Is everyone okay with the charter language now? &nbs= p;Russ will post a new complete version just to make sure, but can we send = this to the IESG and ask for the work group?
>
> Brian

=3D =3D =3D =3D =3D =3D =3D =3D

Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: Richard Barnes

Mailing list: stir@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

The STIR working group will specify mechanisms for the validation of source= telephone number for an incoming call.  Since it has become fairly ea= sy to present an incorrect source telephone number, a growing set of proble= ms have emerged over the last decade.  As with email, the claimed source identity of a SIP request is not v= erified, permitting unauthorized use of the source identity as part of dece= ptive and coercive activities, such as robocalling (bulk unsolicited commer= cial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to e= mergency services to stimulate unwarranted large scale law enforcement depl= oyments).  In addition, use of an incorrect source telephone number fa= cilitates wire fraud or lead to a return call at premium rates.  This working group will define mechanisms tha= t verify the authorization of the calling party to use a particular telepho= ne number.

SIP is one of the main VoIP technologies used by parties that want to prese= nt an incorrect origin, in this context an origin telephone number.
Several previous efforts have tried to secure the origins of SIP communicat= ions, including RFC 3325, RFC 4474, and the VIPR working group.
To date, however, true validation of the source of SIP calls has not seen a= ny appreciable deployment.  Several factors contributed to this lack o= f success, including: failure of the problem to be seen as critical at the = time; lack of any technical means of producing a proof of authority over telephone numbers; misalignment of the= mechanisms proposed by RFC 4474 with the complex deployment environment th= at has emerged for SIP; lack of end-to-end SIP session establishment; and i= nherent operational problems with a transitive trust model.  To make deployment of this solution more l= ikely, consideration must be given to latency, real-time performance, compu= tational overhead, and administrative overhead for the legitimate call sour= ce and all verifiers.

As its priority mechanism work item, the working group will specify a SIP h= eader-based mechanism to verify the originator of a SIP session is authoriz= ed to use the claimed source telephone number, where the session is establi= shed with SIP end to end.  This is called an in-band mechanism.
The mechanism will use a canonical telephone number representation specifie= d by the working group, including any mappings that might be needed between= the SIP header fields and the canonical telephone number representation. &= nbsp;The working group will consider choices for protecting identity information and credentials used, but will= likely be based on a digital signature mechanism that covers a set of info= rmation in the SIP header fields, and verification will employ a credential= that contains the public key and is associated with the one or more telephone numbers.
In order to be authoritative, credentials used with this mechanism will be = derived from existing telephone number assignment and delegation models. &n= bsp;That is, when a telephone number or range of telephone numbers is deleg= ated to an entity, relevant credentials will be generated (or
modified) to reflect such delegation.  The mechanism must allow a tele= phone number holder to further delegate and revoke use of a telephone numbe= r without compromising the global delegation scheme.

In addition to its priority mechanism work item, the working group will con= sider session establishment where there are one or more non-SIP hops, most = likely using an out-of-band mechanism.  However, the in-band and the o= ut-of-band mechanisms should share as much in common as possible, especially the credentials.  The in-band = mechanism must be sent to the IESG for approval and publication prior to th= e out-of-band mechanism.

Expansion of the authorization mechanism to identities using the user@domai= n form deferred since the main focus of the working group is to develop a s= olution for telephone numbers.

The working group will coordinate with the Security Area on credential mana= gement.

The working group will coordinate with other working groups in the RAI Area= regarding signaling through existing deployments.

Authentication and authori_______________________________________________ stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--_000_E6A16181E5FD2F46B962315BB05962D01FBA89BDp2pxmb13fccnetw_-- From fas_vm@surguttel.ru Tue Aug 13 09:05:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D9821F9DC9 for ; Tue, 13 Aug 2013 09:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.472 X-Spam-Level: ** X-Spam-Status: No, score=2.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, J_BACKHAIR_31=1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb0WOCyeWs1h for ; Tue, 13 Aug 2013 09:05:41 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 346D611E8184 for ; Tue, 13 Aug 2013 09:05:35 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id E241B51385A; Tue, 13 Aug 2013 22:05:28 +0600 (YEKT) Received: from Gateway (unknown [151.252.74.183]) by mail.s86.ru (Postfix) with ESMTPA id AB3C4513817; Tue, 13 Aug 2013 22:05:25 +0600 (YEKT) Message-ID: <2DC8CB8897ED4834B6920647F24DC5B6@Gateway> From: "Anton Tveretin" To: "Hadriel Kaplan" References: <7D8ECCC0A7324280A8C243CAAB895C93@Gateway> Date: Tue, 13 Aug 2013 22:02:39 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130813-0, 13.08.2013), Outbound message X-Antivirus-Status: Clean Cc: stir@ietf.org Subject: Re: [stir] draft-kaplan-stir-ikes-out X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:05:47 -0000 I think we should discuss scenarios involving different networks first. Consider a SIP-> PSTN call. The gateway IMO should perform validation, and transcode IKES information. But caller might have only SIP AoR (e-mail-style) and no telephony-style number. So the caller becomes unknown. Also, it is unlikely that anyone will do validation on PSTN side. PSTN -> SIP. Probably IKES is not deployed on PSTN side. So the gateway should supply it. SIP -> PSTN -> SIP. The second gateway must recognize IKES even though it does no validation. Remember that caller might be unknown? I do not know whether SIP<->H.323 gateways exist. SIP->PSTN->H.323? IKES would be available to the callee, but not to gatekeepers, unless it is delivered with RAS. But it is GK that admits or not. So "do not admit unvalidated calls" policy implies that IKES is passed with RAS. Of course, scenarios as SIP->PSTN->H.323->PSTN->SIP->PSTN->H.323 are also possible, esp. if consider private networks. I think it is nothing wrong with covering other protocols. Or, should say RFC 2225 (IPOA) be approved by ITU? Everything in this message is under question (?). ----- Original Message ----- From: "Hadriel Kaplan" To: "Anton Tveretin" Cc: Sent: Monday, August 05, 2013 1:27 AM Subject: Re: [stir] draft-kaplan-stir-ikes-out On Aug 4, 2013, at 2:26 PM, "Anton Tveretin" wrote: > Why should addresses be included into IKES? IMO that adds nothing but > extra work > for each validator. By "included" you mean included in the IKES-IF string encoded in the message itself, e.g. the LIKES-IF SIP header? It's only included that way in SIP and XMPP. It's included in them for two reasons: 1) To provide a quick match mechanism that can be performed before having to retrieve a cert/pub-key and performing public key crypto. If the canonical identities the verifier generates from the received To/From URIs don't match the ones in the LIKES-IF header, it knows it's a failure and not to bother checking the signature. If they match, then it goes and checks the signature. It's an optimization, but a useful optimization, especially for call-forwarding cases to figure out which destination identity to check the signature for. 2) To provide troubleshooting help. There's a concern that the "canonicalization" process performed by the signer and verifier domains might lead to different identities, resulting in a IKES verification failure when it should instead succeed. By having the signer insert its values into the new header, the admin of the receiving domain can figure out if his canonicalization policies are wrong or not. > Chapter 11 (error): in DSS1, call termination is done with 3 messages > (DISCONNECT/RELEASE/RELEASE COMPLETE). In H.225.0 call control, just one > (RELEASE COMPLETE). This error must be corrected. Yup, good catch - will do on next revision. > H.225.0 call control contains h323-uu-pdu, which coexists with > user-information, and thus it actually does not count to 131 bytes of ISDN > User-to-User IE. So I think it is possible to combine all ISDN (ISUP, > DSS1, H.225.0 CC). Yeah I knew H.225 could have its own - in fact one could just define new ASN definitions for real/defined fields for the IKES information. See below for more on that... > But, for H.323 it would be more critical to supply IKES in RAS (e.g. ARQ) > and H.501 messages IMO. Why is it critically important for RAS? > Yes, H.323 Forum might have a different opinion about H.323 dying. Anyway, > H.323 users deserve new features, practice shows that. Huh. I was under the impression is was on its last legs, even in video conferencing. (but then I don't personally focus on the video conferencing market, so I could be way off there) Regardless, I can certainly update the draft for H.323 usage, and I will remove the incorrect claim that its dead. Do you think it would be better to just remove H.323 from this draft completely, and let the relevant parts for H.323 be worked out in H-series docs by the ITU/whomever? That way we don't have to have any new ASN definitions for the IKES information in this IKES draft, for example. > And what about other networks, e.g. GSM? Right now the draft just says: "Other protocols wishing to support IKES need to define their own mapping to the values defined in this document." I didn't want to go and document one for every possible protocol in this one IKES document - I figure if IKES gets deployed and used then other protocol groups will do so in their own documentation, if they want to. Like for example BICC, IAX, etc. All I wanted to do was prove it could be done for other protocols, and in particular define how it could work for SIP and SS7/ISUP. Even the XMPP usage might be better off in a separate doc, in the IETF STOX working group or in an XSF XEP. -hadriel From fas_vm@surguttel.ru Tue Aug 13 09:49:33 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D61321F8E7C for ; Tue, 13 Aug 2013 09:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.972 X-Spam-Level: * X-Spam-Status: No, score=1.972 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeAmC7upDre5 for ; Tue, 13 Aug 2013 09:49:27 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6861221F8AF4 for ; Tue, 13 Aug 2013 09:49:27 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id CE82F5138A3; Tue, 13 Aug 2013 22:49:19 +0600 (YEKT) Received: from Gateway (unknown [151.252.74.183]) by mail.s86.ru (Postfix) with ESMTPA id 72E99513820; Tue, 13 Aug 2013 22:49:16 +0600 (YEKT) Message-ID: <4FB237674191471E87CC73D78A5BA0A9@Gateway> From: "Anton Tveretin" To: "Henning Schulzrinne" , Date: Tue, 13 Aug 2013 22:42:48 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130813-0, 13.08.2013), Outbound message X-Antivirus-Status: Clean Subject: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:49:33 -0000 I would point out that in addition to anonymous calls, there are "unknown". Ideally, when a caller or another party (forwarder, answerer, tranferred-to) wants to be anonymous (i.e. hide his/her AOR), s/he will be. Otherwise, his/her AOR is delivered to other parties. In practice, this may be just impossible, as with SS5 links (they still exist), or address space mismatch (see my previous post for an example: e-mail-style addresses are not supported in SS7). I call them "unknown". I think both cases (anonymous and unknown) have nothing common with STIR; we want to assert identity of those who also want it. BTW, sip:anonymous@anonymous.invalid seems to be de facto standard. What's about sip:unknown@unknown.invalid or whatever? From kent@bbn.com Tue Aug 13 09:53:07 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2171821E80B3 for ; Tue, 13 Aug 2013 09:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlBqdunHxMvV for ; Tue, 13 Aug 2013 09:53:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5163711E81A4 for ; Tue, 13 Aug 2013 09:53:01 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50864) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V9Hq8-000Kki-Da; Tue, 13 Aug 2013 12:53:00 -0400 Message-ID: <520A646C.9030909@bbn.com> Date: Tue, 13 Aug 2013 12:53:00 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Eric Burger References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> In-Reply-To: <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:53:07 -0000 Eric, OK, then we ought to do better than *67 :-). Steve On 8/8/13 7:54 PM, Eric Burger wrote: > *67 only blocks the delivery of the caller ID to the called party. The network gets it, even often up to the called party's PBX. This relies on the good graces of the PBX implementor to honor the privacy bit. From kent@bbn.com Tue Aug 13 10:01:59 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC7E21E813A for ; Tue, 13 Aug 2013 10:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkdivJRJIOL1 for ; Tue, 13 Aug 2013 10:01:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AB0DA21E8143 for ; Tue, 13 Aug 2013 10:01:53 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50865) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V9Hyj-000L0J-5w; Tue, 13 Aug 2013 13:01:53 -0400 Message-ID: <520A6681.4030508@bbn.com> Date: Tue, 13 Aug 2013 13:01:53 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <51FA0753.6020600@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org Mail List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 17:01:59 -0000 Hadriel, The threat doc was prepared rather late in the process, after the RPKI work was done (published as RFCs), but before the BGPSEC work was completed. So, we had the advantage (burden?) of reviewing the RPKI threats, since BGPSEC relies on the RPKI. For the STIR context, I'd suggest staring with the threat characterization (adversary classes, capabilities, and motivations). Then discuss components of the systems and how they might be attacked, based on the threat exposition. Since this is a doc being prepared early in the process, I would expect less detail, especially in the attack discussion. As for MITM, one reason that I have suggested generating a doc of this sort is to clarify where MITM attacks are viewed as out of scope. Is it in all points in the system, or only some? Steve From michael.hammer@yaanatech.com Tue Aug 13 10:08:29 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4C21E8148 for ; Tue, 13 Aug 2013 10:08:19 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5FKgVSZ0e6Y for ; Tue, 13 Aug 2013 10:08:01 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 1759021E80B3 for ; Tue, 13 Aug 2013 10:08:01 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 13 Aug 2013 10:07:55 -0700 From: Michael Hammer To: "kent@bbn.com" , "eburger@standardstrack.com" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOjgt3HpeE9YPMkUaRYUJB0cUb+pmHkDsAgAGVQ4CAA1jigIAHZgQA//+MTGA= Date: Tue, 13 Aug 2013 17:07:54 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> In-Reply-To: <520A646C.9030909@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.69] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0176_01CE9826.1E786930" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 17:08:30 -0000 ------=_NextPart_000_0176_01CE9826.1E786930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Could we try to avoid sliding down the slippery slope of designing a bunch of supplementary services? If we have to do it, let's focus on one: assert number, sign it, validate it. Put out RFC. We already have an assert anonymous feature. This just needs to define how you sign that. Anything more starts getting into vendor's implementations. Granted we have to have some of the others in back of mind. But as someone who one had to test 400+ features on a major vendor's switch, this could easily diverge into a feature beauty contest. Whether you use this one new feature or not, or block it in some way is next release. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, August 13, 2013 12:53 PM To: Eric Burger Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Eric, OK, then we ought to do better than *67 :-). Steve On 8/8/13 7:54 PM, Eric Burger wrote: > *67 only blocks the delivery of the caller ID to the called party. The network gets it, even often up to the called party's PBX. This relies on the good graces of the PBX implementor to honor the privacy bit. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0176_01CE9826.1E786930 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx MzE3MDc1MlowIwYJKoZIhvcNAQkEMRYEFNUO+IfrFbh7N4V5lxxndgVfYfUvMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAIkEbL+mjVNBDg4zJzoJ4xyZ7tz0gq9CVOk81hQn1 /TWWNJn6hxXILzUoHUvuGba1L9zCOje8HkvPoNLxUPUbD/jW0zDHkEJ4oJxOdMw/EPfPsonKhEl7 luqgH9HX6TGVCmK2zNujSn2lZCqNiVVq9jMvUnnH5rRlcevThKScHcgy0/ZRHtFdPNr3TWBJV+Nn azdtOBpab9w1Gi4U7UV4rWEH6SbNIQ6NIE4LgbYAhhZ5AQZkazAGr3HbkWgoRIFzWW9NjEQCzeRX OT5xLigyhzd8PuMj2r8Z3mE16sFqEEvL5u77YUGETJhv3ylampO92swDSUg7vb9o+RIzld/nJgAA AAAAAA== ------=_NextPart_000_0176_01CE9826.1E786930-- From dhc@dcrocker.net Tue Aug 13 10:20:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBE611E8172 for ; Tue, 13 Aug 2013 10:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6Uan3EN1BGc for ; Tue, 13 Aug 2013 10:19:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0168411E8150 for ; Tue, 13 Aug 2013 10:19:56 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7DHJpMg021836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Aug 2013 10:19:54 -0700 Message-ID: <520A6AAA.5070208@dcrocker.net> Date: Tue, 13 Aug 2013 10:19:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Hammer References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 13 Aug 2013 10:19:54 -0700 (PDT) Cc: "stir@ietf.org" , "kent@bbn.com" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 17:20:02 -0000 On 8/13/2013 10:07 AM, Michael Hammer wrote: > Could we try to avoid sliding down the slippery slope of designing a bunch > of supplementary services? > If we have to do it, let's focus on one: assert number, sign it, validate > it. Put out RFC. > > We already have an assert anonymous feature. This just needs to define how > you sign that. Is that really needed? Offhand, it sounds like it wouldn't be useful... The point behind 'anonymous' is to refrain from asserting a meaningful identity. In the absence of such an assertion, it doesn't mean anything to 'validate' the Caller-ID. In other words, your nice, simple suggestion for focus looks exactly right, with the note that not all caller-ids will be (or need to be) signed, and notably not 'anonymous'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Tue Aug 13 10:47:04 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DF611E8118 for ; Tue, 13 Aug 2013 10:47:04 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs392yGnYvWu for ; Tue, 13 Aug 2013 10:47:00 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0827B11E81A2 for ; Tue, 13 Aug 2013 10:46:58 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 13 Aug 2013 10:46:57 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOjgt3HpeE9YPMkUaRYUJB0cUb+pmHkDsAgAGVQ4CAA1jigIAHZgQA//+MTGCAAHslAP//kgyQ Date: Tue, 13 Aug 2013 17:46:57 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC27DFA@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <520A6AAA.5070208@dcrocker.net> In-Reply-To: <520A6AAA.5070208@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.69] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_01F6_01CE982B.93419ED0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "kent@bbn.com" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 17:47:05 -0000 ------=_NextPart_000_01F6_01CE982B.93419ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Only wanted to consider the possibility mentioned before of known by carrier, but anonymous otherwise. Mike -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Tuesday, August 13, 2013 1:20 PM To: Michael Hammer Cc: kent@bbn.com; eburger@standardstrack.com; stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On 8/13/2013 10:07 AM, Michael Hammer wrote: > Could we try to avoid sliding down the slippery slope of designing a > bunch of supplementary services? > If we have to do it, let's focus on one: assert number, sign it, > validate it. Put out RFC. > > We already have an assert anonymous feature. This just needs to > define how you sign that. Is that really needed? Offhand, it sounds like it wouldn't be useful... The point behind 'anonymous' is to refrain from asserting a meaningful identity. In the absence of such an assertion, it doesn't mean anything to 'validate' the Caller-ID. In other words, your nice, simple suggestion for focus looks exactly right, with the note that not all caller-ids will be (or need to be) signed, and notably not 'anonymous'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ------=_NextPart_000_01F6_01CE982B.93419ED0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx MzE3NDY1NlowIwYJKoZIhvcNAQkEMRYEFMJhg9v48aqLQWR4coP+Ie3NBc7aMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEALcb//+5NX8uLe76cL4avCejJ93uA4D1r9W352btl KukgjxubhRNs+EnzUBOuX6/fYrc1cJIyWCqT6fUwMK8Rl0eLz1eKqNprI3Au9Zh6ZyFEk60Uclz0 Bucp1fXS8gV2cD4so3G7EFYoDE6D2mimjyG0ZgRfaMdGLhv73hXUs6/5toBxn1tD7elY8fLax3GP f1SvjyZ5Jd45K9WGHcKupXH/TjeDLrFk9cEVlAgLahS1y1khlywZicoofL6tlKJr5t8XnS7Ijx5I aD7wY6W9oJAqmAzeumboqUlFeNC9OcpEemRvcglufF5m2SGNktfDEQjkqGplgH4OqOVpSmABjwAA AAAAAA== ------=_NextPart_000_01F6_01CE982B.93419ED0-- From fluffy@cisco.com Tue Aug 13 11:05:18 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B684311E8192 for ; Tue, 13 Aug 2013 11:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJHJIKleT5+L for ; Tue, 13 Aug 2013 11:05:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BD70F21F91B7 for ; Tue, 13 Aug 2013 11:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7576; q=dns/txt; s=iport; t=1376417113; x=1377626713; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fQBEN7CrqeZVMlyEmV7aOouHBHBTQG8FBWxTLDZrrWw=; b=WbUL/GWFgWlXv9qXDJb9DS/SRcZ0Yokmt01l6Y+7w8iGtXwg0YZcE3Sf Mk/rHractTeRPV4q8K912EI/gZep5w8nSuCz7qurFrRE+ZVAzwR6VNmbR klOh0Ki+mak/TF2Z7t3IWbTpLvhLKyypupvy4mAIgI5Yig4TAhah0eKT0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAGp0ClKtJV2c/2dsb2JhbABPAwmDBjVQvmCBIhZ0giQBAQEDAQEBARodHxULBQsCAQgiAhIQJwslAgQOAwIIE4dvBgy4FwSOagEEB4ETAjEHgxt2A5QNlSiDG0CBKAIHFwIEHA X-IronPort-AV: E=Sophos;i="4.89,871,1367971200"; d="scan'208";a="246829154" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 13 Aug 2013 18:05:08 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7DI571w003393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 18:05:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 13:05:07 -0500 From: "Cullen Jennings (fluffy)" To: Russ Housley Thread-Topic: [stir] Moving from BOF to Charter Thread-Index: AQHOmE+kcDxbcC6AT0W+rDL+Mc0Flw== Date: Tue, 13 Aug 2013 18:05:06 +0000 Message-ID: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <1D1609F6FD950049B539B190BCD7BDD7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 18:05:18 -0000 Looks good. Ship it.=20 On Aug 9, 2013, at 8:00 AM, Russ Housley wrote: > Below is the current charter text. Is it ready for the IESG? >=20 > Russ >=20 >> Thanks. >>=20 >> Is that it? Is everyone okay with the charter language now? Russ will = post a new complete version just to make sure, but can we send this to the = IESG and ask for the work group? >>=20 >> Brian >=20 > =3D =3D =3D =3D =3D =3D =3D =3D=20 >=20 > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: Richard Barnes >=20 > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir >=20 > The STIR working group will specify mechanisms for the validation of > source telephone number for an incoming call. Since it > has become fairly easy to present an incorrect source telephone number, a > growing set of problems have emerged over the last decade. As with > email, the claimed source identity of a SIP request is not verified, > permitting unauthorized use of the source identity as part of deceptive > and coercive activities, such as robocalling (bulk unsolicited commercial > communications), vishing (voicemail hacking, and impersonating banks) and > swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, use > of an incorrect source telephone number facilitates wire fraud or lead to > a return call at premium rates. This working group will define > mechanisms that verify the authorization of the calling party to use a > particular telephone number. >=20 > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not seen > any appreciable deployment. Several factors contributed to this lack of > success, including: failure of the problem to be seen as critical at the > time; lack of any technical means of producing a proof of authority over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack of > end-to-end SIP session establishment; and inherent operational problems > with a transitive trust model. To make deployment of this solution more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. >=20 > As its priority mechanism work item, the working group will specify a SIP > header-based mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, where the session > is established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone number > representation. The working group will consider choices for protecting > identity information and credentials used, but will likely be based on a > digital signature mechanism that covers a set of information in the SIP > header fields, and verification will employ a credential that contains > the public key and is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow a > telephone number holder to further delegate and revoke use of a telephone > number without compromising the global delegation scheme. >=20 > In addition to its priority mechanism work item, the working group will > consider session establishment where there are one or more non-SIP hops, > most likely using an out-of-band mechanism. However, the in-band and the > out-of-band mechanisms should share as much in common as possible, > especially the credentials. The in-band mechanism must be sent to the > IESG for approval and publication prior to the out-of-band mechanism. >=20 > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is to > develop a solution for telephone numbers. >=20 > The working group will coordinate with the Security Area on credential > management. >=20 > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. >=20 > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. A called > party will receive an indication that the source telephone number is > unavailable in order to provide anonymity. This working group, to the > extent feasible, will specify privacy-friendly mechanisms that do not > reveal any more information to user agents or third parties than a call > that does not make use of secure telephone identification mechanisms. >=20 > Input to working group discussions shall include: >=20 > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] >=20 > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] >=20 > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] >=20 > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] >=20 > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] >=20 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity >=20 > - A threat model for the secure telephone identity mechanisms >=20 > - A privacy analysis of the secure telephone identity mechanisms >=20 > - A mechanism document describing the SIP end-to-end with telephone > number-based identities=20 >=20 > - A document describing the credentials required to support > telephone number identity authentication >=20 > - A fallback mechanism to allow out-of-band identity establishment > during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Tue Aug 13 11:12:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F423B21E80E8 for ; Tue, 13 Aug 2013 11:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJzRanmYV9Tr for ; Tue, 13 Aug 2013 11:12:30 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F094221F8BD8 for ; Tue, 13 Aug 2013 11:12:29 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7DICBxg025714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Aug 2013 11:12:14 -0700 Message-ID: <520A76E8.8000100@dcrocker.net> Date: Tue, 13 Aug 2013 11:11:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Hammer References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <520A6AAA.5070208@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC27DFA@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC27DFA@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 13 Aug 2013 11:12:15 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 18:12:35 -0000 On 8/13/2013 10:46 AM, Michael Hammer wrote: > Only wanted to consider the possibility mentioned before of known by > carrier, but anonymous otherwise. That's a very specialized semantic. It's not entirely clear what benefit it would produce, and it's not obvious how the semantic would be encoded. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From richard@shockey.us Tue Aug 13 11:27:03 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748F411E8129 for ; Tue, 13 Aug 2013 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRMEOB0kIn9N for ; Tue, 13 Aug 2013 11:26:58 -0700 (PDT) Received: from oproxy14-pub.mail.unifiedlayer.com (oproxy14-pub.mail.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 9D1A511E80EA for ; Tue, 13 Aug 2013 11:26:58 -0700 (PDT) Received: (qmail 27413 invoked by uid 0); 13 Aug 2013 18:14:49 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 13 Aug 2013 18:14:49 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=S74jVTV/QBCcGft0ZQzbD4hX5Ik5I96LXnDfS8PaMm4=; b=n0gp5BiqhRT/7KEB9fWK+6crXqltxqkDPnag7AUQM5i/bl5kEQHqpO6jWXb//hQ2OA+jNMQLTGtS7A4GMhxllMK4tVsanoHIjlY4mazq9BSfdH6CfiEygYwYzFJQTob1; Received: from [71.114.100.16] (port=56975 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V9J7I-0003LC-Ay; Tue, 13 Aug 2013 12:14:48 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> Date: Tue, 13 Aug 2013 14:14:44 -0400 Message-ID: <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAmNFLYoCnpukhgIjunD9AcypclECnwcp9wH9UiaQmEGnDsA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 18:27:03 -0000 Well that's fine for now but in the future you have to consider how to display enhanced user, anonymous, unknown, validation data on the User Agents. CNAM only gives you 15 ASCII characters and I'm going to assume someone might like something better in the future. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, August 13, 2013 1:08 PM To: kent@bbn.com; eburger@standardstrack.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Could we try to avoid sliding down the slippery slope of designing a bunch of supplementary services? If we have to do it, let's focus on one: assert number, sign it, validate it. Put out RFC. We already have an assert anonymous feature. This just needs to define how you sign that. Anything more starts getting into vendor's implementations. Granted we have to have some of the others in back of mind. But as someone who one had to test 400+ features on a major vendor's switch, this could easily diverge into a feature beauty contest. Whether you use this one new feature or not, or block it in some way is next release. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, August 13, 2013 12:53 PM To: Eric Burger Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Eric, OK, then we ought to do better than *67 :-). Steve On 8/8/13 7:54 PM, Eric Burger wrote: > *67 only blocks the delivery of the caller ID to the called party. The network gets it, even often up to the called party's PBX. This relies on the good graces of the PBX implementor to honor the privacy bit. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From kent@bbn.com Tue Aug 13 11:32:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC4B11E8198 for ; Tue, 13 Aug 2013 11:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWnpwEfWoQ78 for ; Tue, 13 Aug 2013 11:32:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3A011E80EA for ; Tue, 13 Aug 2013 11:32:17 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50907) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V9JO7-000MxY-Ap; Tue, 13 Aug 2013 14:32:11 -0400 Message-ID: <520A7BAB.9020305@bbn.com> Date: Tue, 13 Aug 2013 14:32:11 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Russ Housley References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> In-Reply-To: <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lucy Lynch , IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 18:32:23 -0000 Russ, > Merging suggestions from other, I come up with: > > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. A called > party will receive an indication that the source telephone number has > been blocked to provide anonymity. This working group, to the extent > feasible, will specify privacy-friendly mechanisms that do not reveal > any more information to third parties than a call that does not make > use of secure telephone identification mechanisms. > > Does that work for you? > > Russ > I like the first few sentences. Given the additional info provided by Eric re who along the call path see what caller ID info, we probably should say that we plan to explore options re privacy in that arena. Steve From kent@bbn.com Tue Aug 13 11:36:54 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB7A11E81BC for ; Tue, 13 Aug 2013 11:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSGiJAEUv9jV for ; Tue, 13 Aug 2013 11:36:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD2D21E8176 for ; Tue, 13 Aug 2013 11:36:34 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50908) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V9JSJ-000N3N-Ue for stir@ietf.org; Tue, 13 Aug 2013 14:36:31 -0400 Message-ID: <520A7CAF.7050706@bbn.com> Date: Tue, 13 Aug 2013 14:36:31 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 CC: IETF STIR Mail List References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 18:36:54 -0000 Russ, I'm comfortable with the current charter text. Steve From rlb@ipv.sx Tue Aug 13 12:08:44 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624EA21E804E for ; Tue, 13 Aug 2013 12:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToyZJCRwkfHa for ; Tue, 13 Aug 2013 12:08:39 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id ADAF421E8186 for ; Tue, 13 Aug 2013 12:08:39 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so10244618obp.8 for ; Tue, 13 Aug 2013 12:08:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lwepneuVTU+Wx6/v8gW5/O6236I0Dwf7q7xZG94zyvo=; b=OLjz8YdpwO9TK+L0TaB1v96QQXJ/WDopwY+Xt1YUriFU+5FDxf93hsvxgtP6oFiQgN 8Rbs22E0zc9RnLyYZjFY/dicLqUe3kNzpqHHV6qfebhElbGj4VJ85v30ofKQ9rpMULlM 8VhSlXR82BsxOcQicrv2E0nA/uiNEnHW+Ra3UOdl+cT1Jf0eeX0mNGGTzZCPZJl6sXVi V0VI0JyxHh75s8d3yVwg1heQgAbvhKhOp6jfQj2o2lnMks67W7gV+JNRNL+u+Wpjpyfb jwqncICc7gXkxvEiiTzG627RrmEZiLSlQZO/Crvd5+5KWLkO8zCuusBzgiT0yfbVca0h jA2g== X-Gm-Message-State: ALoCoQnefgnCOJqrkilJhs/9cL6LOZpnNDUXgD+yYHjjEb8OOzm+Kz3e9fJprEhyWElEZ4PU/6Bi MIME-Version: 1.0 X-Received: by 10.182.236.103 with SMTP id ut7mr300222obc.3.1376420919199; Tue, 13 Aug 2013 12:08:39 -0700 (PDT) Received: by 10.60.80.228 with HTTP; Tue, 13 Aug 2013 12:08:39 -0700 (PDT) X-Originating-IP: [192.1.48.2] In-Reply-To: <520A7CAF.7050706@bbn.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> <520A7CAF.7050706@bbn.com> Date: Tue, 13 Aug 2013 15:08:39 -0400 Message-ID: From: Richard Barnes To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11c30e50f362a004e3d8f733 Cc: IETF STIR Mail List Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 19:08:45 -0000 --001a11c30e50f362a004e3d8f733 Content-Type: text/plain; charset=ISO-8859-1 Thanks, everyone. I've sent the charter to the IESG for approval. --Richard On Tue, Aug 13, 2013 at 2:36 PM, Stephen Kent wrote: > Russ, > > I'm comfortable with the current charter text. > > Steve > > > ______________________________**_________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/**listinfo/stir > --001a11c30e50f362a004e3d8f733 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, everyone. =A0I've sent the charter to the IESG= for approval.
--Richard


=
On Tue, Aug 13, 2013 at 2:36 PM, Stephen Kent <kent@= bbn.com> wrote:
Russ,

I'm comfortable with the current charter text.

Steve


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--001a11c30e50f362a004e3d8f733-- From hadriel.kaplan@oracle.com Tue Aug 13 12:51:00 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D851A21E8177 for ; Tue, 13 Aug 2013 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LfFuahhQk0n for ; Tue, 13 Aug 2013 12:50:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 20FED21E80C3 for ; Tue, 13 Aug 2013 12:50:44 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7DJogp5005306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Aug 2013 19:50:42 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7DJoeDJ017093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Aug 2013 19:50:41 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7DJoepu014140; Tue, 13 Aug 2013 19:50:40 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Aug 2013 12:50:40 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Hadriel Kaplan X-Priority: 3 In-Reply-To: <4FB237674191471E87CC73D78A5BA0A9@Gateway> Date: Tue, 13 Aug 2013 15:50:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3E46E00B-176E-44F7-972D-FFA16D2ED50B@oracle.com> References: <4FB237674191471E87CC73D78A5BA0A9@Gateway> To: Anton Tveretin X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org Subject: Re: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 19:51:00 -0000 On Aug 13, 2013, at 12:42 PM, Anton Tveretin = wrote: > I would point out that in addition to anonymous calls, there are = "unknown". > Ideally, when a caller or another party (forwarder, answerer, = tranferred-to) wants to be anonymous (i.e. hide his/her AOR), s/he will = be. Otherwise, his/her AOR is delivered to other parties. In practice, = this may be just impossible, as with SS5 links (they still exist), or = address space mismatch (see my previous post for an example: = e-mail-style addresses are not supported in SS7). I call them "unknown". > I think both cases (anonymous and unknown) have nothing common with = STIR; we want to assert identity of those who also want it. > BTW, sip:anonymous@anonymous.invalid seems to be de facto standard. = What's about sip:unknown@unknown.invalid or whatever?=20 'sip:anonymous@anonymous.invalid' is not just a defacto - it's in the = original RFC that way. See here: http://tools.ietf.org/html/rfc3323#section-4.1.1.3 As you point out, there is a subtle difference between 'anonymous' and = 'unknown' - in that there's a difference between user-presented = caller-id display saying "blocked" vs. "unknown". Some devices today do = use "sip:unknown@unknown.invalid", and it's even documented to be used = in RFC 6044, ETSI, and 3GPP for History-Info placeholder cases. But = it's never been truly specified anywhere as meaning anything special in = a =46rom URI, as far as I know. -hadriel From hadriel.kaplan@oracle.com Tue Aug 13 13:15:21 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4F721E818E for ; Tue, 13 Aug 2013 13:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_31=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YuZafUBvwZH for ; Tue, 13 Aug 2013 13:15:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id E064321E8181 for ; Tue, 13 Aug 2013 13:15:11 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7DKF8CQ028775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Aug 2013 20:15:09 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7DKEtki011698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Aug 2013 20:15:08 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7DKEtcR024500; Tue, 13 Aug 2013 20:14:55 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Aug 2013 13:14:55 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Hadriel Kaplan X-Priority: 3 In-Reply-To: <2DC8CB8897ED4834B6920647F24DC5B6@Gateway> Date: Tue, 13 Aug 2013 16:14:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7D8ECCC0A7324280A8C243CAAB895C93@Gateway> <2DC8CB8897ED4834B6920647F24DC5B6@Gateway> To: Anton Tveretin X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] draft-kaplan-stir-ikes-out X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:15:21 -0000 On Aug 13, 2013, at 12:02 PM, Anton Tveretin = wrote: > I think we should discuss scenarios involving different networks = first. > Consider a SIP-> PSTN call. The gateway IMO should perform validation, = and transcode IKES information. But caller might have only SIP AoR = (e-mail-style) and no telephony-style number. So the caller becomes = unknown. Also, it is unlikely that anyone will do validation on PSTN = side. I'm not following you. If a SIP user only has an email-style source = identity with no corresponding telephone number, there's not much we can = do about that. The user will either get a generic domain-wide or = gateway telephone number (as Skype users do, for example), or they'll be = anonymous (or 'unknown' as you mentioned in another email). > PSTN -> SIP. Probably IKES is not deployed on PSTN side. So the = gateway should supply it. Sorry I don't understand in what way you mean that. Supply what? If the call comes in from the PSTN without IKES, there are 3 things the = PSTN-SIP gateway can do: 1) it can copy the CgPN into the SIP From, but can't generate an IKEs = thing for it since it's not authoritative for the CgPN and doesn't have = a private key to sign it with. (nor should it) 2) it can generate a =46rom using some generic telephone number assigned = to the gateway, which it can theoretically generate an IKES signature = for but probably shouldn't. 3) it can generate an anonymous (or 'unknown') From, which obviously = means no IKES signature. Are you saying it should do (1) but with an IKES signature, or are you = saying it should do (2) but with an IKES signature? > SIP -> PSTN -> SIP. The second gateway must recognize IKES even though = it does no validation. Remember that caller might be unknown? I don't follow what you're asking/pointing-out above. > I do not know whether SIP<->H.323 gateways exist. Yup, plenty do. > SIP->PSTN->H.323? IKES would be available to the callee, but not to = gatekeepers, unless it is delivered with RAS. But it is GK that admits = or not. So "do not admit unvalidated calls" policy implies that IKES is = passed with RAS. Hmmm... yeah I can see that, but not sure if it makes more sense to just = have the GW perform the IKES verification, and then send the GK a flag = in the RAS indicating it's been successful or failed to validate. =20 ISTM this type of thing is better decided in ETSI or ITU or someplace = that makes H.323 standards decisions... so I think it makes more sense = to pull H.323 out of the IEKS draft and leave it up to another SDO to = decide how to handle. > Of course, scenarios as SIP->PSTN->H.323->PSTN->SIP->PSTN->H.323 are = also possible, esp. if consider private networks. > I think it is nothing wrong with covering other protocols. Or, should = say RFC 2225 (IPOA) be approved by ITU? We do cover other SDO protocols in the IETF, and even multiple SDO = protocols in one RFC - but my impression is we only do that when there's = sufficient expertise in the IETF to do so, or when we get contributions = from the other SDO. Afaik, there are very few people in the IETF who = are active in H.323 anymore - there are some in the video side, and a = couple in other places, but I wouldn't be comfortable deciding anything = about it without reaching out to the other SDOs. -hadriel From pkyzivat@alum.mit.edu Tue Aug 13 14:28:37 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C2E21E8180 for ; Tue, 13 Aug 2013 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDNNb8becGiI for ; Tue, 13 Aug 2013 14:28:26 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id EF0C721E8187 for ; Tue, 13 Aug 2013 14:28:22 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id CD4f1m00327AodY5AMUL6E; Tue, 13 Aug 2013 21:28:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id CMUL1m0043ZTu2S3fMULbg; Tue, 13 Aug 2013 21:28:20 +0000 Message-ID: <520AA4F2.9070707@alum.mit.edu> Date: Tue, 13 Aug 2013 23:28:18 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <4FB237674191471E87CC73D78A5BA0A9@Gateway> <3E46E00B-176E-44F7-972D-FFA16D2ED50B@oracle.com> In-Reply-To: <3E46E00B-176E-44F7-972D-FFA16D2ED50B@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376429300; bh=B0YJYq86q6CPDeOigFMJZr0lW41l8sTWZ4xmWyo5Mfw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Trzncu3jXfjAZoBPm/0PTQBggk+kZdRJ71jh7C0mZ/pUFFIqfZZ1nJahdFwUEfLSl /SNnOziCrZMQ4Xtxsj8kFG62/TsjiyMLeKoVahAFOx598v5caXZkObueIGFviLMjW8 88yRBodqIq8Tag3h8QQKCvoNGGdgKZbF2W+3BoCkQhbP6GPl4MXgSJBhoTKBBNuDTi Wbi2IOF+wIF74StU58GKu2wfkuwe1mMGUgsxoVMamoClbuUiBoKYErrMM6goE3+Rzx c0XeskPLeb/PrYduCFi67QKcGeeg0B/pnX3JeenhMUIv8sQicGFLBFmLKOKmHMIV/I SWycXKWLX3Xew== Subject: Re: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:28:37 -0000 On 8/13/13 9:50 PM, Hadriel Kaplan wrote: > Some devices today do use "sip:unknown@unknown.invalid", and it's even documented to be used in RFC 6044, ETSI, and 3GPP for History-Info placeholder cases. But it's never been truly specified anywhere as meaning anything special in a From URI, as far as I know. Anything in the "invalid" TLD is "interesting". AFAIK this is not a valid TLD (duh). But that means it isn't possible to register any subdomains of it. So what is the justification for calling out a particular subdomain, and user within that subdomain, to have particular semantics? And its vaguely possible (though unlikely) that ICANN would make "invalid" a valid TLD. Perhaps "invalid" and anonymous.invalid need to be properly registered, much as example.com and example.org are, so that the assignment and use of subdomains can be controlled. Meanwhile, ISTM that any URL with "invalid" as its TLD should be considered to be an indication of intent to provide an unreachable address. Thanks, Paul From hadriel.kaplan@oracle.com Tue Aug 13 14:55:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A58211E813B for ; Tue, 13 Aug 2013 14:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYtLG8hMCEDv for ; Tue, 13 Aug 2013 14:55:48 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id EC88B21F9F77 for ; Tue, 13 Aug 2013 14:55:46 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7DLthq2009613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Aug 2013 21:55:44 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7DLtfF8029925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Aug 2013 21:55:43 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7DLtf97012059; Tue, 13 Aug 2013 21:55:41 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Aug 2013 14:55:41 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <520AA4F2.9070707@alum.mit.edu> Date: Tue, 13 Aug 2013 17:55:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6EEBDE4C-42FF-4AC4-9F06-C1B4FF08FB1C@oracle.com> References: <4FB237674191471E87CC73D78A5BA0A9@Gateway> <3E46E00B-176E-44F7-972D-FFA16D2ED50B@oracle.com> <520AA4F2.9070707@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:55:59 -0000 On Aug 13, 2013, at 5:28 PM, Paul Kyzivat wrote: > On 8/13/13 9:50 PM, Hadriel Kaplan wrote: >=20 >> Some devices today do use "sip:unknown@unknown.invalid", and it's = even documented to be used in RFC 6044, ETSI, and 3GPP for History-Info = placeholder cases. But it's never been truly specified anywhere as = meaning anything special in a =46rom URI, as far as I know. >=20 > Anything in the "invalid" TLD is "interesting". >=20 > AFAIK this is not a valid TLD (duh). But that means it isn't possible = to register any subdomains of it. So what is the justification for = calling out a particular subdomain, and user within that subdomain, to = have particular semantics? >=20 > And its vaguely possible (though unlikely) that ICANN would make = "invalid" a valid TLD. 'invalid' is a reserved domain name by IANA, in both RFC 2606 and 6761, = and in IANA's registry here: http://www.iana.org/assignments/special-use-domain-names > Perhaps "invalid" and anonymous.invalid need to be properly = registered, much as example.com and example.org are, so that the = assignment and use of subdomains can be controlled. Right, that's basically the question. It seems weird to register = subdomains for something that has a semantic of being invalid, but maybe = it should be done. -hadriel From jon.peterson@neustar.biz Tue Aug 13 15:07:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB2311E813B for ; Tue, 13 Aug 2013 15:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.446 X-Spam-Level: X-Spam-Status: No, score=-105.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sui1l1vTTbCS for ; Tue, 13 Aug 2013 15:07:07 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 46B1411E80E8 for ; Tue, 13 Aug 2013 15:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1376432183; x=1691786662; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=VN3evY3nZ4 8tDbL3YCFqmSIHOYVK18UV+m17ZAqPCgQ=; b=PgymZJ0VWyaE5E9tVHtVugP/CU gtksH2JwXksr30LB/cMllONVG5ND/BZIHtUbmyLCGQx5dJggwHR6Z5gib4Kw== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.29817654; Tue, 13 Aug 2013 18:16:22 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.190]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 13 Aug 2013 18:06:57 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) Thread-Index: AQHOmHFtOeGXjG2yZkqbV9XHum0hzA== Date: Tue, 13 Aug 2013 22:06:57 +0000 Message-ID: In-Reply-To: <6EEBDE4C-42FF-4AC4-9F06-C1B4FF08FB1C@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.145] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: b9yMIaOa3KJ5La6K8SV4sA== Content-Type: text/plain; charset="us-ascii" Content-ID: <7E5E0E09D99D1541B424F08196988452@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:07:11 -0000 Our understanding at the time we did RFC3323 was that there was no need to register sudomains under the .invalid TLD. We supplied a subdomain to be generous to simple SIP URI parsers and avoid ambiguity (as the recent IAB statement on TLDs-as-domain-names affirms). Probably we could just as easily have chosen sip:invalid, but when a UI rendered the URI to the recipient we wanted it be clear that anonymity had been explicitly asserted.=20 For .com and .org, it was necessary to reserve the second level name "example" because otherwise it could be assigned; there is no similar risk for anything under .invalid, as nothing under the TLD can be assigned or resolved. Jon Peterson Neustar, Inc. On 8/13/13 2:55 PM, "Hadriel Kaplan" wrote: > > >On Aug 13, 2013, at 5:28 PM, Paul Kyzivat wrote: > >> On 8/13/13 9:50 PM, Hadriel Kaplan wrote: >>=20 >>> Some devices today do use "sip:unknown@unknown.invalid", and it's even >>>documented to be used in RFC 6044, ETSI, and 3GPP for History-Info >>>placeholder cases. But it's never been truly specified anywhere as >>>meaning anything special in a From URI, as far as I know. >>=20 >> Anything in the "invalid" TLD is "interesting". >>=20 >> AFAIK this is not a valid TLD (duh). But that means it isn't possible >>to register any subdomains of it. So what is the justification for >>calling out a particular subdomain, and user within that subdomain, to >>have particular semantics? >>=20 >> And its vaguely possible (though unlikely) that ICANN would make >>"invalid" a valid TLD. > > >'invalid' is a reserved domain name by IANA, in both RFC 2606 and 6761, >and in IANA's registry here: >http://www.iana.org/assignments/special-use-domain-names > > >> Perhaps "invalid" and anonymous.invalid need to be properly registered, >>much as example.com and example.org are, so that the assignment and use >>of subdomains can be controlled. > >Right, that's basically the question. It seems weird to register >subdomains for something that has a semantic of being invalid, but maybe >it should be done. > >-hadriel > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Tue Aug 13 15:23:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF06521F9BD3 for ; Tue, 13 Aug 2013 15:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiwFFfxbW0eV for ; Tue, 13 Aug 2013 15:23:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 88AF721F9C68 for ; Tue, 13 Aug 2013 15:23:44 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7DMNXxc021782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Aug 2013 22:23:34 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7DMNXXX017066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Aug 2013 22:23:33 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7DMNXLV011257; Tue, 13 Aug 2013 22:23:33 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Aug 2013 15:23:32 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 13 Aug 2013 18:23:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F16122B-6E6C-44DC-B675-88ECA1747308@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:23:50 -0000 Oh I'm not claiming we *have* to register it, because clearly we don't - = just sayin' we might *want* to. :) I.e., if we ever want to make a distinction between 'anonymous' and = 'unknown', for display purposes for example. -hadriel On Aug 13, 2013, at 6:06 PM, "Peterson, Jon" = wrote: >=20 > Our understanding at the time we did RFC3323 was that there was no = need to > register sudomains under the .invalid TLD. We supplied a subdomain to = be > generous to simple SIP URI parsers and avoid ambiguity (as the recent = IAB > statement on TLDs-as-domain-names affirms). Probably we could just as > easily have chosen sip:invalid, but when a UI rendered the URI to the > recipient we wanted it be clear that anonymity had been explicitly > asserted.=20 >=20 > For .com and .org, it was necessary to reserve the second level name > "example" because otherwise it could be assigned; there is no similar = risk > for anything under .invalid, as nothing under the TLD can be assigned = or > resolved. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 8/13/13 2:55 PM, "Hadriel Kaplan" = wrote: >=20 >>=20 >>=20 >> On Aug 13, 2013, at 5:28 PM, Paul Kyzivat = wrote: >>=20 >>> On 8/13/13 9:50 PM, Hadriel Kaplan wrote: >>>=20 >>>> Some devices today do use "sip:unknown@unknown.invalid", and it's = even >>>> documented to be used in RFC 6044, ETSI, and 3GPP for History-Info >>>> placeholder cases. But it's never been truly specified anywhere as >>>> meaning anything special in a =46rom URI, as far as I know. >>>=20 >>> Anything in the "invalid" TLD is "interesting". >>>=20 >>> AFAIK this is not a valid TLD (duh). But that means it isn't = possible >>> to register any subdomains of it. So what is the justification for >>> calling out a particular subdomain, and user within that subdomain, = to >>> have particular semantics? >>>=20 >>> And its vaguely possible (though unlikely) that ICANN would make >>> "invalid" a valid TLD. >>=20 >>=20 >> 'invalid' is a reserved domain name by IANA, in both RFC 2606 and = 6761, >> and in IANA's registry here: >> http://www.iana.org/assignments/special-use-domain-names >>=20 >>=20 >>> Perhaps "invalid" and anonymous.invalid need to be properly = registered, >>> much as example.com and example.org are, so that the assignment and = use >>> of subdomains can be controlled. >>=20 >> Right, that's basically the question. It seems weird to register >> subdomains for something that has a semantic of being invalid, but = maybe >> it should be done. >>=20 >> -hadriel >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Tue Aug 13 15:43:13 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9C221E8196 for ; Tue, 13 Aug 2013 15:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMvoGtSAYsRR for ; Tue, 13 Aug 2013 15:43:08 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 367EF21E8082 for ; Tue, 13 Aug 2013 15:43:08 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta15.westchester.pa.mail.comcast.net with comcast id CN0W1m00517dt5G5FNj6xZ; Tue, 13 Aug 2013 22:43:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id CNj61m0033ZTu2S3ZNj62o; Tue, 13 Aug 2013 22:43:06 +0000 Message-ID: <520AB678.8020401@alum.mit.edu> Date: Wed, 14 Aug 2013 00:43:04 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <7F16122B-6E6C-44DC-B675-88ECA1747308@oracle.com> In-Reply-To: <7F16122B-6E6C-44DC-B675-88ECA1747308@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376433786; bh=0F0Q/GToJNb6EEmV33cNLYc8/g/c4coYeb6FNOx4mic=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gL/XSTGd+vjFrSgl3W3yLTwHg6m/31ucB4fgX3/BMqaR3OHTeFLzUoiiaetncIEyK e45xdTmWXtlGOcNkhjHiLZekLUNYINyhoDARLCzSqXglUcE3Qx4e2vVdrJGeUZYOcN n9jD2SOtfvp0UMeDGixQSUcwqjScmouKy10Hx+ojuziCqLgw+AWaTjWF6d8uDEMDb0 2D5JXlLG0We+nVq6Kz0z6GwDrWEmYwh7gv2IwyRn+k7hroDntf/s22L6TSmPCjcQuE jqZsHVnjZFpCZCmnjNkQw/CrGRRDww9ynAslfgn0A4P8NDS6ZEoX6rrOANJ4E6oK5M BSreX37pYdLiQ== Cc: "stir@ietf.org" , "Peterson, Jon" Subject: Re: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:43:13 -0000 I didn't know about 6761 and its discussion of "invalid". Live and learn. That at least will prevent ICANN from assigning it to somebody. On 8/14/13 12:23 AM, Hadriel Kaplan wrote: > > Oh I'm not claiming we *have* to register it, because clearly we don't - just sayin' we might *want* to. > :) > > I.e., if we ever want to make a distinction between 'anonymous' and 'unknown', for display purposes for example. If we want to ascribe specific meaning to a particular derivative of "invalid" then there ought to be some place to stake a claim to that, so it isn't used for something different. Ideally one could use whois to identify the owner. That works for example.com and example.org - it shows up as owned by IANA. But 6761 prevents registrars from accepting "normal" registrations under "invalid". But this is all a nit. Thanks, Paul > -hadriel > > > > On Aug 13, 2013, at 6:06 PM, "Peterson, Jon" wrote: > >> >> Our understanding at the time we did RFC3323 was that there was no need to >> register sudomains under the .invalid TLD. We supplied a subdomain to be >> generous to simple SIP URI parsers and avoid ambiguity (as the recent IAB >> statement on TLDs-as-domain-names affirms). Probably we could just as >> easily have chosen sip:invalid, but when a UI rendered the URI to the >> recipient we wanted it be clear that anonymity had been explicitly >> asserted. >> >> For .com and .org, it was necessary to reserve the second level name >> "example" because otherwise it could be assigned; there is no similar risk >> for anything under .invalid, as nothing under the TLD can be assigned or >> resolved. >> >> Jon Peterson >> Neustar, Inc. >> >> On 8/13/13 2:55 PM, "Hadriel Kaplan" wrote: >> >>> >>> >>> On Aug 13, 2013, at 5:28 PM, Paul Kyzivat wrote: >>> >>>> On 8/13/13 9:50 PM, Hadriel Kaplan wrote: >>>> >>>>> Some devices today do use "sip:unknown@unknown.invalid", and it's even >>>>> documented to be used in RFC 6044, ETSI, and 3GPP for History-Info >>>>> placeholder cases. But it's never been truly specified anywhere as >>>>> meaning anything special in a From URI, as far as I know. >>>> >>>> Anything in the "invalid" TLD is "interesting". >>>> >>>> AFAIK this is not a valid TLD (duh). But that means it isn't possible >>>> to register any subdomains of it. So what is the justification for >>>> calling out a particular subdomain, and user within that subdomain, to >>>> have particular semantics? >>>> >>>> And its vaguely possible (though unlikely) that ICANN would make >>>> "invalid" a valid TLD. >>> >>> >>> 'invalid' is a reserved domain name by IANA, in both RFC 2606 and 6761, >>> and in IANA's registry here: >>> http://www.iana.org/assignments/special-use-domain-names >>> >>> >>>> Perhaps "invalid" and anonymous.invalid need to be properly registered, >>>> much as example.com and example.org are, so that the assignment and use >>>> of subdomains can be controlled. >>> >>> Right, that's basically the question. It seems weird to register >>> subdomains for something that has a semantic of being invalid, but maybe >>> it should be done. >>> >>> -hadriel >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > From jon.peterson@neustar.biz Tue Aug 13 16:36:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34DB11E80D1 for ; Tue, 13 Aug 2013 16:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.723 X-Spam-Level: X-Spam-Status: No, score=-105.723 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I01Z4gD19LcE for ; Tue, 13 Aug 2013 16:36:36 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 04A6921E804B for ; Tue, 13 Aug 2013 16:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1376436977; x=1691789662; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=z0AJUGvnfV 5NaSJxw+cJ/Vk3i660aUNJ1+uVdLcqgU4=; b=XF/8BMTeF8Kj+kqp7A4q3dymLb 9FHXbYQbBxQh5mW8u3PCKlAmEerkviP8ZP8CPb+g4t26f+3kCbcvmfGN+RAQ== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.23842535; Tue, 13 Aug 2013 19:36:15 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.190]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 13 Aug 2013 19:36:26 -0400 From: "Peterson, Jon" To: Paul Kyzivat , Hadriel Kaplan Thread-Topic: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) Thread-Index: AQHOmHFtOeGXjG2yZkqbV9XHum0hzJmT+aaAgAAFdgD//5mNgA== Date: Tue, 13 Aug 2013 23:36:25 +0000 Message-ID: In-Reply-To: <520AB678.8020401@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.145] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: wgYcxbywLROSa/j4VaGMjA== Content-Type: text/plain; charset="us-ascii" Content-ID: <8D47E184252B5B4C9797CC597CF4D745@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:36:40 -0000 I'm not sure I see any real risk of code point collision or something in using anonymous.invalid as a domain name such that we need a registry or IANA procedure. I do however agree that the anonymous URI defined in RFC3323 applies to a case where the caller intends to be anonymous, not to a case where the caller's identity is simply unknown by the system, perhaps because the call came from a gateway where the protocol on the other side supplied no identity. Certainly an RFC3323 anonymous URI would not be appropriate for that case. But what is? Maybe the "unknown" From that Hadriel pointed to. Jon Peterson Neustar, Inc. On 8/13/13 3:43 PM, "Paul Kyzivat" wrote: >I didn't know about 6761 and its discussion of "invalid". Live and >learn. That at least will prevent ICANN from assigning it to somebody. > >On 8/14/13 12:23 AM, Hadriel Kaplan wrote: >> >> Oh I'm not claiming we *have* to register it, because clearly we don't >>- just sayin' we might *want* to. >> :) >> >> I.e., if we ever want to make a distinction between 'anonymous' and >>'unknown', for display purposes for example. > >If we want to ascribe specific meaning to a particular derivative of >"invalid" then there ought to be some place to stake a claim to that, so >it isn't used for something different. > >Ideally one could use whois to identify the owner. That works for >example.com and example.org - it shows up as owned by IANA. But 6761 >prevents registrars from accepting "normal" registrations under "invalid". > >But this is all a nit. > > Thanks, > Paul > >> -hadriel >> >> >> >> On Aug 13, 2013, at 6:06 PM, "Peterson, Jon" >>wrote: >> >>> >>> Our understanding at the time we did RFC3323 was that there was no >>>need to >>> register sudomains under the .invalid TLD. We supplied a subdomain to >>>be >>> generous to simple SIP URI parsers and avoid ambiguity (as the recent >>>IAB >>> statement on TLDs-as-domain-names affirms). Probably we could just as >>> easily have chosen sip:invalid, but when a UI rendered the URI to the >>> recipient we wanted it be clear that anonymity had been explicitly >>> asserted. >>> >>> For .com and .org, it was necessary to reserve the second level name >>> "example" because otherwise it could be assigned; there is no similar >>>risk >>> for anything under .invalid, as nothing under the TLD can be assigned >>>or >>> resolved. >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> On 8/13/13 2:55 PM, "Hadriel Kaplan" wrote: >>> >>>> >>>> >>>> On Aug 13, 2013, at 5:28 PM, Paul Kyzivat >>>>wrote: >>>> >>>>> On 8/13/13 9:50 PM, Hadriel Kaplan wrote: >>>>> >>>>>> Some devices today do use "sip:unknown@unknown.invalid", and it's >>>>>>even >>>>>> documented to be used in RFC 6044, ETSI, and 3GPP for History-Info >>>>>> placeholder cases. But it's never been truly specified anywhere as >>>>>> meaning anything special in a From URI, as far as I know. >>>>> >>>>> Anything in the "invalid" TLD is "interesting". >>>>> >>>>> AFAIK this is not a valid TLD (duh). But that means it isn't possible >>>>> to register any subdomains of it. So what is the justification for >>>>> calling out a particular subdomain, and user within that subdomain, >>>>>to >>>>> have particular semantics? >>>>> >>>>> And its vaguely possible (though unlikely) that ICANN would make >>>>> "invalid" a valid TLD. >>>> >>>> >>>> 'invalid' is a reserved domain name by IANA, in both RFC 2606 and >>>>6761, >>>> and in IANA's registry here: >>>> http://www.iana.org/assignments/special-use-domain-names >>>> >>>> >>>>> Perhaps "invalid" and anonymous.invalid need to be properly >>>>>registered, >>>>> much as example.com and example.org are, so that the assignment and >>>>>use >>>>> of subdomains can be controlled. >>>> >>>> Right, that's basically the question. It seems weird to register >>>> subdomains for something that has a semantic of being invalid, but >>>>maybe >>>> it should be done. >>>> >>>> -hadriel >>>> >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> >> > From pkyzivat@alum.mit.edu Tue Aug 13 17:02:59 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E1C11E80D2 for ; Tue, 13 Aug 2013 17:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKolYur-9ihC for ; Tue, 13 Aug 2013 17:02:55 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC8C11E80D1 for ; Tue, 13 Aug 2013 17:02:55 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta07.westchester.pa.mail.comcast.net with comcast id CNAf1m0021ap0As57Q2vxl; Wed, 14 Aug 2013 00:02:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id CQ2u1m01B3ZTu2S3iQ2u4E; Wed, 14 Aug 2013 00:02:54 +0000 Message-ID: <520AC92D.1020204@alum.mit.edu> Date: Wed, 14 Aug 2013 02:02:53 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Peterson, Jon" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376438575; bh=2bK5DiSynUQMNJqrBf72sQeXz+r8qD2QQcarC0MxuZQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EYKgJFAWKe5sZoHBQT0ACE/b6aEwZpLT3Z1AinUBgaJY0fhdwTgXIfWAaGUgtcEz/ iQmlP6SfmODK+inU5fjmCNriGAGb8jeAw2DgoxVwFbDlmSvdATAsBdawqyBt6zXeNh xvFmRxExLNRh8PTrYhSkUD8aXNQS4RNLBh8OvACC0CBHlJAYSDaGvrxYQPD74hNwkK xlYlCkxR+naCGJjnOJdwkiJyR18ecAa4ZUncOLPAbDfLEIoVgbYC0y5giFJW9uMhcO ccp2/M5UafjHB1C2TS/ts+eA5HKXj/DUN+U+D6453TzGc+fXrZx1r8euuoET0kawAm R2ASF6THDagyg== Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 00:03:00 -0000 On 8/14/13 1:36 AM, Peterson, Jon wrote: > > I'm not sure I see any real risk of code point collision or something in > using anonymous.invalid as a domain name such that we need a registry or > IANA procedure. I'm wearing my obsessive-compulsive hat here. I realize there isn't a big risk of this being used for something conflicting. But the more special significance we assign to this the more we should be concerned that people encountering this usage can *discover* what it means. (As hard as it may be for people here to understand, not everybody doing sip has read every sip-related RFC. I've read most of them, but I didn't know about 6761.) I have never been too concerned about the usage in 3261. (Though if i were doing it over I would probably try to fix it.) But there is is really sufficient that the address not be resolvable. Any address that was guaranteed not to be resolvable would have been sufficient. Maybe that is true here too. But if we want to say users should get one sort of callerid for sip:anonymous@anonymous.invalid, and a different sort of callerid for other unresolvable From addresses, and yet a different sort of callerid for tel URIs that aren't signed, then it gets more important. Thanks, Paul > I do however agree that the anonymous URI defined in RFC3323 applies to a > case where the caller intends to be anonymous, not to a case where the > caller's identity is simply unknown by the system, perhaps because the > call came from a gateway where the protocol on the other side supplied no > identity. Certainly an RFC3323 anonymous URI would not be appropriate for > that case. But what is? Maybe the "unknown" From that Hadriel pointed to. > > Jon Peterson > Neustar, Inc. > > On 8/13/13 3:43 PM, "Paul Kyzivat" wrote: > >> I didn't know about 6761 and its discussion of "invalid". Live and >> learn. That at least will prevent ICANN from assigning it to somebody. >> >> On 8/14/13 12:23 AM, Hadriel Kaplan wrote: >>> >>> Oh I'm not claiming we *have* to register it, because clearly we don't >>> - just sayin' we might *want* to. >>> :) >>> >>> I.e., if we ever want to make a distinction between 'anonymous' and >>> 'unknown', for display purposes for example. >> >> If we want to ascribe specific meaning to a particular derivative of >> "invalid" then there ought to be some place to stake a claim to that, so >> it isn't used for something different. >> >> Ideally one could use whois to identify the owner. That works for >> example.com and example.org - it shows up as owned by IANA. But 6761 >> prevents registrars from accepting "normal" registrations under "invalid". >> >> But this is all a nit. >> >> Thanks, >> Paul >> >>> -hadriel >>> >>> >>> >>> On Aug 13, 2013, at 6:06 PM, "Peterson, Jon" >>> wrote: >>> >>>> >>>> Our understanding at the time we did RFC3323 was that there was no >>>> need to >>>> register sudomains under the .invalid TLD. We supplied a subdomain to >>>> be >>>> generous to simple SIP URI parsers and avoid ambiguity (as the recent >>>> IAB >>>> statement on TLDs-as-domain-names affirms). Probably we could just as >>>> easily have chosen sip:invalid, but when a UI rendered the URI to the >>>> recipient we wanted it be clear that anonymity had been explicitly >>>> asserted. >>>> >>>> For .com and .org, it was necessary to reserve the second level name >>>> "example" because otherwise it could be assigned; there is no similar >>>> risk >>>> for anything under .invalid, as nothing under the TLD can be assigned >>>> or >>>> resolved. >>>> >>>> Jon Peterson >>>> Neustar, Inc. >>>> >>>> On 8/13/13 2:55 PM, "Hadriel Kaplan" wrote: >>>> >>>>> >>>>> >>>>> On Aug 13, 2013, at 5:28 PM, Paul Kyzivat >>>>> wrote: >>>>> >>>>>> On 8/13/13 9:50 PM, Hadriel Kaplan wrote: >>>>>> >>>>>>> Some devices today do use "sip:unknown@unknown.invalid", and it's >>>>>>> even >>>>>>> documented to be used in RFC 6044, ETSI, and 3GPP for History-Info >>>>>>> placeholder cases. But it's never been truly specified anywhere as >>>>>>> meaning anything special in a From URI, as far as I know. >>>>>> >>>>>> Anything in the "invalid" TLD is "interesting". >>>>>> >>>>>> AFAIK this is not a valid TLD (duh). But that means it isn't possible >>>>>> to register any subdomains of it. So what is the justification for >>>>>> calling out a particular subdomain, and user within that subdomain, >>>>>> to >>>>>> have particular semantics? >>>>>> >>>>>> And its vaguely possible (though unlikely) that ICANN would make >>>>>> "invalid" a valid TLD. >>>>> >>>>> >>>>> 'invalid' is a reserved domain name by IANA, in both RFC 2606 and >>>>> 6761, >>>>> and in IANA's registry here: >>>>> http://www.iana.org/assignments/special-use-domain-names >>>>> >>>>> >>>>>> Perhaps "invalid" and anonymous.invalid need to be properly >>>>>> registered, >>>>>> much as example.com and example.org are, so that the assignment and >>>>>> use >>>>>> of subdomains can be controlled. >>>>> >>>>> Right, that's basically the question. It seems weird to register >>>>> subdomains for something that has a semantic of being invalid, but >>>>> maybe >>>>> it should be done. >>>>> >>>>> -hadriel >>>>> >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>> >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>> >>> >> > > From richard@shockey.us Tue Aug 13 18:33:05 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5320311E81D0 for ; Tue, 13 Aug 2013 18:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY5wTQFHkl1p for ; Tue, 13 Aug 2013 18:33:00 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 7772A11E81D4 for ; Tue, 13 Aug 2013 18:33:00 -0700 (PDT) Received: (qmail 17657 invoked by uid 0); 14 Aug 2013 01:32:38 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.mail.unifiedlayer.com with SMTP; 14 Aug 2013 01:32:38 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=vao7MrrxOLl574RzwfELO7es0Bz4cZWIVH6R6OlnDxM=; b=jHamJ9NPorC1zbwUul6B+ngWBnO4hPilDQhCyBZsiZCsLD1/dgu8buOTjAk6bqNyG2xhwhxUPF4mxxNQ+mlq9BHZTN6rM442oKIgBhk2am1Xu8pDUZOFuOCorYd7W7zi; Received: from [71.114.100.16] (port=61477 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V9Px0-0000Oj-27; Tue, 13 Aug 2013 19:32:38 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> In-Reply-To: <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> Date: Tue, 13 Aug 2013 21:32:34 -0400 Message-ID: <015101ce988e$27aa1900$76fe4b00$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAmNFLYoCnpukhgIjunD9AcypclECnwcp9wH9UiaQAehfhtOYMtstYA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 01:33:05 -0000 I'm sorry to be a skunk here but no one as bothered to answer my question or elaborate a theory of how CUA's display rich text reputation data? What is the successor to CNAM? What can the network deliver to the consumer that they may or may not be able to make a judgment on. I call the pizza place it returns a HTTP on specials before the call is delivered.. And validates the data etc. UPS/FEDEX the inbound SMS delivers rich text delivery data in real time. What the network can process is almost irrelevant if the CUA can't display it. Its orthogonal to the STIR problem statement but you can't ignore the implications. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, August 13, 2013 2:15 PM To: 'Michael Hammer'; kent@bbn.com; eburger@standardstrack.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Well that's fine for now but in the future you have to consider how to display enhanced user, anonymous, unknown, validation data on the User Agents. CNAM only gives you 15 ASCII characters and I'm going to assume someone might like something better in the future. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, August 13, 2013 1:08 PM To: kent@bbn.com; eburger@standardstrack.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Could we try to avoid sliding down the slippery slope of designing a bunch of supplementary services? If we have to do it, let's focus on one: assert number, sign it, validate it. Put out RFC. We already have an assert anonymous feature. This just needs to define how you sign that. Anything more starts getting into vendor's implementations. Granted we have to have some of the others in back of mind. But as someone who one had to test 400+ features on a major vendor's switch, this could easily diverge into a feature beauty contest. Whether you use this one new feature or not, or block it in some way is next release. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, August 13, 2013 12:53 PM To: Eric Burger Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Eric, OK, then we ought to do better than *67 :-). Steve On 8/8/13 7:54 PM, Eric Burger wrote: > *67 only blocks the delivery of the caller ID to the called party. The network gets it, even often up to the called party's PBX. This relies on the good graces of the PBX implementor to honor the privacy bit. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Tue Aug 13 19:20:25 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8821E81AE for ; Tue, 13 Aug 2013 19:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XVRUNY-9D-9 for ; Tue, 13 Aug 2013 19:20:19 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id D7A1121E81A9 for ; Tue, 13 Aug 2013 19:20:18 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id CS7p1m0061GhbT851SLJ18; Wed, 14 Aug 2013 02:20:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id CSLH1m0153ZTu2S3TSLJbg; Wed, 14 Aug 2013 02:20:18 +0000 Message-ID: <520AE960.8020800@alum.mit.edu> Date: Wed, 14 Aug 2013 04:20:16 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> In-Reply-To: <015101ce988e$27aa1900$76fe4b00$@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376446818; bh=Eff9Nh3WGRiu6ixpyaAD+wFcfgzv9Urm0C+Q6YSPrYY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rRvnsJaZ6Bk2L34otmC0ve8tSzGWn5SdAPvJanUy2ZD0P9JJAfsuRlquyFgSyAB0s HOJ/Nu2WC4QRKXv9zSKoFe7CeDpznAvdh25BqkoLOC4AstyplQU8QWyINLagpgxKaR xJ5TXuoll6tX2qcyJyNXuPHVLMU/Wf1B9P/huIfhNoJ/qoflnNTiy7wKFZbbLLLBhu rLUmSfN9+uzI2HYv9M69abUe9fGYToj8TQAGJk3maJLr50yYkr9GQa9P1JUTKkcKoo xiZ63d/QhI34ZQWWNbLHus+T0Dq49XShpa54Mo2Sz9j+pOZWKFCjEj8+nUbihsWLdC Qgno8qsnvWVpw== Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 02:20:25 -0000 On 8/14/13 3:32 AM, Richard Shockey wrote: > > I'm sorry to be a skunk here but no one as bothered to answer my question or > elaborate a theory of how CUA's display rich text reputation data? > > What is the successor to CNAM? That's an interesting question. If there were a cert per phone number, then the CNAM data could be in the cert, eliminating another retrieval. But it seems that isn't being viewed as an attractive way to go. Otherwise, it remains yet another DB that needs to be queried. At least that query could be in parallel with verifying the signature on the number. Thanks, Paul > What can the network deliver to the consumer that they may or may not be > able to make a judgment on. > > I call the pizza place it returns a HTTP on specials before the call > is delivered.. And validates the data etc. > > UPS/FEDEX the inbound SMS delivers rich text delivery data in real time. > > What the network can process is almost irrelevant if the CUA can't display > it. > > Its orthogonal to the STIR problem statement but you can't ignore the > implications. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Richard Shockey > Sent: Tuesday, August 13, 2013 2:15 PM > To: 'Michael Hammer'; kent@bbn.com; eburger@standardstrack.com > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > Well that's fine for now but in the future you have to consider how to > display enhanced user, anonymous, unknown, validation data on the User > Agents. > > CNAM only gives you 15 ASCII characters and I'm going to assume someone > might like something better in the future. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Michael Hammer > Sent: Tuesday, August 13, 2013 1:08 PM > To: kent@bbn.com; eburger@standardstrack.com > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > Could we try to avoid sliding down the slippery slope of designing a bunch > of supplementary services? > If we have to do it, let's focus on one: assert number, sign it, validate > it. Put out RFC. > > We already have an assert anonymous feature. This just needs to define how > you sign that. > Anything more starts getting into vendor's implementations. > > Granted we have to have some of the others in back of mind. > But as someone who one had to test 400+ features on a major vendor's switch, > > this could easily diverge into a feature beauty contest. > > Whether you use this one new feature or not, or block it in some way is next > release. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Stephen Kent > Sent: Tuesday, August 13, 2013 12:53 PM > To: Eric Burger > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > Eric, > > OK, then we ought to do better than *67 :-). > > Steve > On 8/8/13 7:54 PM, Eric Burger wrote: >> *67 only blocks the delivery of the caller ID to the called party. The > network gets it, even often up to the called party's PBX. This relies on the > good graces of the PBX implementor to honor the privacy bit. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From hadriel.kaplan@oracle.com Wed Aug 14 04:01:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7849B11E81B7 for ; Wed, 14 Aug 2013 04:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZH8vn2M1gyQ for ; Wed, 14 Aug 2013 04:01:43 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 862AE11E81A9 for ; Wed, 14 Aug 2013 04:01:43 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7EB1eaQ030866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Aug 2013 11:01:41 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EB1bOI024286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 11:01:40 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EB1bIw022779; Wed, 14 Aug 2013 11:01:37 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Aug 2013 04:01:37 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <015101ce988e$27aa1900$76fe4b00$@shockey.us> Date: Wed, 14 Aug 2013 07:01:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1A232B3F-2CF4-4343-8435-8FC81409CA78@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 11:01:51 -0000 I don't follow you - as you say it's orthogonal to STIR. STIR validates = the source identity E.614 number, and if that number is legit then it = can be used for a lookup to retrieve CNAM info; or both database lookups = can be done simultaneously and the CNAM info can be used if the = validation is successful. That's assuming you perform a database lookup = for CNAM info for such information. Of course SIP always had the Call-Info header, but it's basically never = used afaik. Historically it was useless because it never made it = through PSTN gateways or B2BUAs, and most SIP UAs don't pay attention to = it. And even if it got sent through you could never trust it. Even if = you knew the caller claiming to be +16035551234 was really from that = E.164 number, you couldn't trust the caller was Fidelity or Citibank or = PayPal or whatever just because it claimed it was, in a Call-Info = header. Using a separate database for that information is better = because the caller couldn't just claim to be whatever it wanted to. Not = that the CNAM database contents are perfect either (my home number has a = wrong CNAM entry, for example)... but it's like a reverse lookup in the = white/yellow pages, and they're generally ok. If you mean where should the CNAM-type info go in SIP, I believe the = most common thing is to put it as the display-name portion of the From. = I'm not saying that's a good place to put it, but that's where I see it = put most often, I think. -hadriel On Aug 13, 2013, at 9:32 PM, Richard Shockey wrote: >=20 > I'm sorry to be a skunk here but no one as bothered to answer my = question or > elaborate a theory of how CUA's display rich text reputation data?=20 >=20 > What is the successor to CNAM?=20 >=20 > What can the network deliver to the consumer that they may or may not = be > able to make a judgment on.=20 >=20 > I call the pizza place it returns a HTTP on specials before the = call > is delivered.. And validates the data etc. =20 >=20 > UPS/FEDEX the inbound SMS delivers rich text delivery data in real = time. =20 >=20 > What the network can process is almost irrelevant if the CUA can't = display > it. =20 >=20 > Its orthogonal to the STIR problem statement but you can't ignore the > implications. =20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Richard Shockey > Sent: Tuesday, August 13, 2013 2:15 PM > To: 'Michael Hammer'; kent@bbn.com; eburger@standardstrack.com > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) >=20 > Well that's fine for now but in the future you have to consider how to > display enhanced user, anonymous, unknown, validation data on the User > Agents. >=20 > CNAM only gives you 15 ASCII characters and I'm going to assume = someone > might like something better in the future.=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Michael Hammer > Sent: Tuesday, August 13, 2013 1:08 PM > To: kent@bbn.com; eburger@standardstrack.com > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) >=20 > Could we try to avoid sliding down the slippery slope of designing a = bunch > of supplementary services? > If we have to do it, let's focus on one: assert number, sign it, = validate > it. Put out RFC. >=20 > We already have an assert anonymous feature. This just needs to = define how > you sign that. > Anything more starts getting into vendor's implementations. >=20 > Granted we have to have some of the others in back of mind. =20 > But as someone who one had to test 400+ features on a major vendor's = switch, >=20 > this could easily diverge into a feature beauty contest. >=20 > Whether you use this one new feature or not, or block it in some way = is next > release. >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Stephen Kent > Sent: Tuesday, August 13, 2013 12:53 PM > To: Eric Burger > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) >=20 > Eric, >=20 > OK, then we ought to do better than *67 :-). >=20 > Steve > On 8/8/13 7:54 PM, Eric Burger wrote: >> *67 only blocks the delivery of the caller ID to the called party. = The > network gets it, even often up to the called party's PBX. This relies = on the > good graces of the PBX implementor to honor the privacy bit. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Wed Aug 14 04:45:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970B411E8131 for ; Wed, 14 Aug 2013 04:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAZ5aSvD+sbd for ; Wed, 14 Aug 2013 04:45:43 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC8811E8134 for ; Wed, 14 Aug 2013 04:45:43 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7EBje0Z022373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Aug 2013 11:45:41 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EBjdYd020099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 11:45:39 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EBjdUC020093; Wed, 14 Aug 2013 11:45:39 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Aug 2013 04:45:39 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <520AE960.8020800@alum.mit.edu> Date: Wed, 14 Aug 2013 07:45:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 11:45:49 -0000 On Aug 13, 2013, at 10:20 PM, Paul Kyzivat = wrote: > That's an interesting question. > If there were a cert per phone number, then the CNAM data could be in = the cert, eliminating another retrieval. There was some discussion around that early on. I think there was = concern about making the signing CAs have to verify CNAM-type info in a = cert signing request before signing it. =20 If they don't perform verification that you really are the name for the = phone-number, then you could claim any name you wanted; if they do = perform verification, it's either through a manual process and very = expensive (as web certs are today), or the CA uses a CNAM database to = populate the info in the cert without letting you choose what to put in = it. =20 It happens to be that in the US the numbering admin contractor and the = most popular CNAM database are the same company, but my guess is there = are regulatory restrictions around how integrated they can be. (I don't = know that to be the case, but it's just a guess that antitrust issues = would make it so... but IANAL) Regardless, it also hits pricing/charging issues. Currently the CNAM = database providers charge the terminating side for retrieval, and I = don't think we want that type of model for STIR at all. (as an aside: = it's always seemed crazy to me that the terminating side pays for CNAM, = rather than the opposite - I know how it came about to be that way, but = I think it's counter-productive today) > But it seems that isn't being viewed as an attractive way to go. I don't know what you mean by that comment? Using certs for STIR is = most definitely on the table. There're pros/cons with any proposed = solution thus far. The CIDER concept has warts too. Ultimately we're = going to have to choose, but there's no "perfect" solution as far as I = can tell. > Otherwise, it remains yet another DB that needs to be queried. Not necessarily. Even with a CIDER approach one could put the CNAM info = in the same database, and in such a way that a single query returns both = STIR and CNAM info at the same time. You could, for example, put it in = a NAPTR like was done in draft-ietf-enum-cnam-08, or you could put it in = another TXT RR, or whatever. Of course if you do that then the CIDER = database could not be made publicly accessible, or at least the CNAM = info record could not be made publicly accessible. But even if the national CIDER database doesn't have the CNAM info, the = local database copies of it in the carriers could integrate the CNAM = info into their local copies. That way they get to have a single = query/response model, even if the data comes from different sources. -hadriel From br@brianrosen.net Wed Aug 14 06:31:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94411E8162 for ; Wed, 14 Aug 2013 06:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXa6o3IkubjV for ; Wed, 14 Aug 2013 06:31:45 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5D85921F9BCA for ; Wed, 14 Aug 2013 06:31:45 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so10101065pad.32 for ; Wed, 14 Aug 2013 06:31:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U4cAEcm3uDigVtVondI9s8t8xrmVFmg7ZCKYTWGFvXc=; b=UrYat9SzDQvRQ2O8uAU+e8KDsQWU8prCyJ7oGwnxEf0GVXk9DLe/xWPQ+aW6W4xlhR RYtgj1VaMqFYvpB264GTbkL6e+nOhHP+92B9unOniZbelll1dgdVDMPT6zheLOayw9/G 9/UjEzQf6YfHaKNjdimqXIAryZ572/zSiOuNlbmSx8oEjNd6og3NdIMLiF7KiQNly+6W /xQXU83ch7jMvF1FSoQqdau2yoSV/Nvin5FVYkCNjZTFcmlg0W5KaSbBUcqCkoSBK4ii cRiNIyd4+p/B+905IqLpBl0Na0Dq4uMjaiWqDfUUCB8ynertCyoeU/WqS18S2vm/dF0g p8AA== X-Gm-Message-State: ALoCoQnpcPwsFL1gQfW9Jh/CW8P1QcGCBTHX+ZA8czl4DBJLXv+LY5YTac/CdJrDYlsMivkpRtX7 MIME-Version: 1.0 X-Received: by 10.68.224.161 with SMTP id rd1mr10010666pbc.121.1376487105020; Wed, 14 Aug 2013 06:31:45 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Wed, 14 Aug 2013 06:31:44 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> Date: Wed, 14 Aug 2013 09:31:44 -0400 Message-ID: From: Brian Rosen To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=e89a8ff24ff6eedef904e3e8601a Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 13:31:50 -0000 --e89a8ff24ff6eedef904e3e8601a Content-Type: text/plain; charset=ISO-8859-1 I think we probably should keep CNAM out of this for now anyway. The advantage of the credential delegation process as we have defined it is that it's authoritative. The current CNAM databases cannot be called "authoritative" really. Classically, as you describe, there is a database operated by on on behalf of the origination carrier and queried by the termination carrier (often with a charge to query). The content is what the carrier has recorde from the original service order, but there isn't any attempt to validate those names, and there are carriers who will let you put anything you like in there. How "authoritative" is that? Then there are other databases, like Neustar's, that don't have any relationship to the originination carrier - the termination carrier dips an independently developed database of name-number relationships. These databases are developed using a wide variety of sources and have evolved to be very accurate, but hardly "authoritative". And yes, Hadriel, there are regulatory restrictions, mostly about what the NPAC (number portability database administrator) can do. The CNAM databases have very few regulations to deal with. Brian On Wednesday, August 14, 2013, Hadriel Kaplan wrote: > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat > > wrote: > > > That's an interesting question. > > If there were a cert per phone number, then the CNAM data could be in > the cert, eliminating another retrieval. > > There was some discussion around that early on. I think there was concern > about making the signing CAs have to verify CNAM-type info in a cert > signing request before signing it. > > If they don't perform verification that you really are the name for the > phone-number, then you could claim any name you wanted; if they do perform > verification, it's either through a manual process and very expensive (as > web certs are today), or the CA uses a CNAM database to populate the info > in the cert without letting you choose what to put in it. > > It happens to be that in the US the numbering admin contractor and the > most popular CNAM database are the same company, but my guess is there are > regulatory restrictions around how integrated they can be. (I don't know > that to be the case, but it's just a guess that antitrust issues would make > it so... but IANAL) > > Regardless, it also hits pricing/charging issues. Currently the CNAM > database providers charge the terminating side for retrieval, and I don't > think we want that type of model for STIR at all. (as an aside: it's always > seemed crazy to me that the terminating side pays for CNAM, rather than the > opposite - I know how it came about to be that way, but I think it's > counter-productive today) > > > > But it seems that isn't being viewed as an attractive way to go. > > I don't know what you mean by that comment? Using certs for STIR is most > definitely on the table. There're pros/cons with any proposed solution > thus far. The CIDER concept has warts too. Ultimately we're going to have > to choose, but there's no "perfect" solution as far as I can tell. > > > > Otherwise, it remains yet another DB that needs to be queried. > > Not necessarily. Even with a CIDER approach one could put the CNAM info > in the same database, and in such a way that a single query returns both > STIR and CNAM info at the same time. You could, for example, put it in a > NAPTR like was done in draft-ietf-enum-cnam-08, or you could put it in > another TXT RR, or whatever. Of course if you do that then the CIDER > database could not be made publicly accessible, or at least the CNAM info > record could not be made publicly accessible. > > But even if the national CIDER database doesn't have the CNAM info, the > local database copies of it in the carriers could integrate the CNAM info > into their local copies. That way they get to have a single query/response > model, even if the data comes from different sources. > > -hadriel > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --e89a8ff24ff6eedef904e3e8601a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we probably should keep CNAM out of this for now anyway.

The advantage of the credential delegation process as we have defi= ned it is that it's authoritative.

The current= CNAM databases cannot be called "authoritative" really. =A0Class= ically, as you describe,=A0there is a database operated by on on behalf of = the origination carrier and queried by the termination carrier (often with= =A0a charge to query). =A0The content is=A0what the carrier has recorde fro= m the original service order,=A0but there isn't any attempt to validate= those names, and there are carriers who will let you put anything you like= in there. =A0How "authoritative" is that? =A0Then there are othe= r databases, like Neustar's,=A0that don't have any relationship to = the originination carrier - the termination carrier dips an independently d= eveloped database of name-number relationships. =A0These databases are deve= loped using a wide variety of sources and have evolved to be very accurate,= but hardly "authoritative".

And yes, Hadriel, there are regulatory restrictions, mo= stly about what the NPAC (number portability database administrator) can do= . The CNAM databases have very few regulations to deal with.

Brian=A0

On Wednesday, Augus= t 14, 2013, Hadriel Kaplan wrote:

On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <pkyziva= t@alum.mit.edu> wrote:

> That's an interesting question.
> If there were a cert per phone number, then the CNAM data could be in = the cert, eliminating another retrieval.

There was some discussion around that early on. =A0I think there was concer= n about making the signing CAs have to verify CNAM-type info in a cert sign= ing request before signing it.

If they don't perform verification that you really are the name for the= phone-number, then you could claim any name you wanted; if they do perform= verification, it's either through a manual process and very expensive = (as web certs are today), or the CA uses a CNAM database to populate the in= fo in the cert without letting you choose what to put in it.

It happens to be that in the US the numbering admin contractor and the most= popular CNAM database are the same company, but my guess is there are regu= latory restrictions around how integrated they can be. (I don't know th= at to be the case, but it's just a guess that antitrust issues would ma= ke it so... but IANAL)

Regardless, it also hits pricing/charging issues. =A0Currently the CNAM dat= abase providers charge the terminating side for retrieval, and I don't = think we want that type of model for STIR at all. (as an aside: it's al= ways seemed crazy to me that the terminating side pays for CNAM, rather tha= n the opposite - I know how it came about to be that way, but I think it= 9;s counter-productive today)


> But it seems that isn't being viewed as an attractive way to go.
I don't know what you mean by that comment? =A0Using certs for STIR is = most definitely on the table. =A0There're pros/cons with any proposed s= olution thus far. =A0The CIDER concept has warts too. =A0Ultimately we'= re going to have to choose, but there's no "perfect" solution= as far as I can tell.


> Otherwise, it remains yet another DB that needs to be queried.

Not necessarily. =A0Even with a CIDER approach one could put the CNAM info = in the same database, and in such a way that a single query returns both ST= IR and CNAM info at the same time. =A0You could, for example, put it in a N= APTR like was done in draft-ietf-enum-cnam-08, or you could put it in anoth= er TXT RR, or whatever. =A0Of course if you do that then the CIDER database= could not be made publicly accessible, or at least the CNAM info record co= uld not be made publicly accessible.

But even if the national CIDER database doesn't have the CNAM info, the= local database copies of it in the carriers could integrate the CNAM info = into their local copies. =A0That way they get to have a single query/respon= se model, even if the data comes from different sources.

-hadriel

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir
--e89a8ff24ff6eedef904e3e8601a-- From pp3129@att.com Wed Aug 14 07:37:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D2A21E8086 for ; Wed, 14 Aug 2013 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fopRwYtcq4GM for ; Wed, 14 Aug 2013 07:37:47 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9AA11E8169 for ; Wed, 14 Aug 2013 07:37:47 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b369b025.6b27c940.4867759.00-596.13533404.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 14 Aug 2013 14:37:47 +0000 (UTC) X-MXL-Hash: 520b963b6b507896-3b41b93e34a2568b3671ca1cf080346c2226a549 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 9369b025.0.4867745.00-490.13533360.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 14 Aug 2013 14:37:46 +0000 (UTC) X-MXL-Hash: 520b963a501fa638-4244c5a63cd9e685a0123571d1583e25061a47ba Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r7EEbiQN000889; Wed, 14 Aug 2013 10:37:45 -0400 Received: from alpi155.enaf.aldc.att.com (alpi155.enaf.aldc.att.com [144.160.229.24]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r7EEbZqO000629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Aug 2013 10:37:36 -0400 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 r7EEbZDo013846; Wed, 14 Aug 2013 10:37:35 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7EEbHC6013523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 10:37:22 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 14 Aug 2013 14:36:57 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([169.254.37.168]) with mapi id 14.02.0342.003; Wed, 14 Aug 2013 10:36:57 -0400 From: "PFAUTZ, PENN L" To: Brian Rosen , Hadriel Kaplan Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKnQk1tpKWU6kSXx4jFw/xpJ5mUw4pA Date: Wed, 14 Aug 2013 14:36:56 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.80] Content-Type: multipart/alternative; boundary="_000_38726EDA2109264987B45E29E758C4D6049AA750MISOUT7MSGUSR9N_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Gsn1DDJC c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=EjBwS5ZnYZMA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=wS_Wgo3JZ] X-AnalysisOut: [60A:10 a=48vgC7mUAAAA:8 a=zRywk9MtrW31aDTQNyIA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=iE9YWIBck50A:10 a=lZB815dzVvQA:10 a=ehAl_fzgxlH] X-AnalysisOut: [HSFpd:21 a=ZpiPj8JY5XPeSliX:21 a=yMhMjlubAAAA:8 a=SSmOFEAC] X-AnalysisOut: [AAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:] X-AnalysisOut: [10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=MZDp3ZAxg5MJeigh:] X-AnalysisOut: [21] Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:37:54 -0000 --_000_38726EDA2109264987B45E29E758C4D6049AA750MISOUT7MSGUSR9N_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I assume the concern in this thread is with the case where a number might b= e authenticated but the CNAM displayed would be misleading because of lax p= olicies of the CNAM provider - e.g., the bad guy makes a call from what is = indeed his legit number but has managed to get Bank of America into his CNA= M entry. I'm thinking that taking on CNAM in the ietf may be a bridge too far for st= ir. Leave what happens after the number is validated up to national authori= ties since arrangements may differ. And at least in the case above it shoul= d be possible to trace back to the perp. More generally I think the object of stir ought to be just to provide the c= ustomer an indication of whether the calling number was validated on not - = whether calls get blocked or unvalidated numbers are still displayed should= be up to the customer and their service provider. Penn Pfautz AT&T Access Management +1-732-420-4962 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Wednesday, August 14, 2013 9:32 AM To: Hadriel Kaplan Cc: stir@ietf.org; Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I think we probably should keep CNAM out of this for now anyway. The advantage of the credential delegation process as we have defined it is= that it's authoritative. The current CNAM databases cannot be called "authoritative" really. Classi= cally, as you describe, there is a database operated by on on behalf of the= origination carrier and queried by the termination carrier (often with a c= harge to query). The content is what the carrier has recorde from the orig= inal service order, but there isn't any attempt to validate those names, an= d there are carriers who will let you put anything you like in there. How = "authoritative" is that? Then there are other databases, like Neustar's, t= hat don't have any relationship to the originination carrier - the terminat= ion carrier dips an independently developed database of name-number relatio= nships. These databases are developed using a wide variety of sources and = have evolved to be very accurate, but hardly "authoritative". And yes, Hadriel, there are regulatory restrictions, mostly about what the = NPAC (number portability database administrator) can do. The CNAM databases= have very few regulations to deal with. Brian On Wednesday, August 14, 2013, Hadriel Kaplan wrote: On Aug 13, 2013, at 10:20 PM, Paul Kyzivat > wrote: > That's an interesting question. > If there were a cert per phone number, then the CNAM data could be in the= cert, eliminating another retrieval. There was some discussion around that early on. I think there was concern = about making the signing CAs have to verify CNAM-type info in a cert signin= g request before signing it. If they don't perform verification that you really are the name for the pho= ne-number, then you could claim any name you wanted; if they do perform ver= ification, it's either through a manual process and very expensive (as web = certs are today), or the CA uses a CNAM database to populate the info in th= e cert without letting you choose what to put in it. It happens to be that in the US the numbering admin contractor and the most= popular CNAM database are the same company, but my guess is there are regu= latory restrictions around how integrated they can be. (I don't know that t= o be the case, but it's just a guess that antitrust issues would make it so= ... but IANAL) Regardless, it also hits pricing/charging issues. Currently the CNAM datab= ase providers charge the terminating side for retrieval, and I don't think = we want that type of model for STIR at all. (as an aside: it's always seeme= d crazy to me that the terminating side pays for CNAM, rather than the oppo= site - I know how it came about to be that way, but I think it's counter-pr= oductive today) > But it seems that isn't being viewed as an attractive way to go. I don't know what you mean by that comment? Using certs for STIR is most d= efinitely on the table. There're pros/cons with any proposed solution thus= far. The CIDER concept has warts too. Ultimately we're going to have to = choose, but there's no "perfect" solution as far as I can tell. > Otherwise, it remains yet another DB that needs to be queried. Not necessarily. Even with a CIDER approach one could put the CNAM info in= the same database, and in such a way that a single query returns both STIR= and CNAM info at the same time. You could, for example, put it in a NAPTR= like was done in draft-ietf-enum-cnam-08, or you could put it in another T= XT RR, or whatever. Of course if you do that then the CIDER database could= not be made publicly accessible, or at least the CNAM info record could no= t be made publicly accessible. But even if the national CIDER database doesn't have the CNAM info, the loc= al database copies of it in the carriers could integrate the CNAM info into= their local copies. That way they get to have a single query/response mod= el, even if the data comes from different sources. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_38726EDA2109264987B45E29E758C4D6049AA750MISOUT7MSGUSR9N_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I assume the concern in t= his thread is with the case where a number might be authenticated but the C= NAM displayed would be misleading because of lax policies of the CNAM provider – e.g., the bad guy makes a call from what is i= ndeed his legit number but has managed to get Bank of America into his CNAM= entry.

 <= /p>

I’m thinking that t= aking on CNAM in the ietf may be a bridge too far for stir. Leave what happ= ens after the number is validated up to national authorities since arrangements may differ. And at least in the case above it should be possi= ble to trace back to the perp.

 <= /p>

More generally I think th= e object of stir ought to be just to provide the customer an indication of = whether the calling number was validated on not – whether calls get blocked or unvalidated numbers are still displayed should be up = to the customer and their service provider.

 <= /p>

Penn Pfautz

AT&T Access Management<= /span>

+1-732-420-4962<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">

From: stir-bou= nces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Wednesday, August 14, 2013 9:32 AM
To: Hadriel Kaplan
Cc: stir@ietf.org; Paul Kyzivat
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Chart= er)

 

I think we probably should keep CNAM out of this for= now anyway.

 

The advantage of the credential delegation process a= s we have defined it is that it's authoritative.

 

The current CNAM databases cannot be called "au= thoritative" really.  Classically, as you describe, there is= a database operated by on on behalf of the origination carrier and queried= by the termination carrier (often with a charge to query).  The content is what the carrier has recorde from the original s= ervice order, but there isn't any attempt to validate those names, and= there are carriers who will let you put anything you like in there.  = How "authoritative" is that?  Then there are other databases= , like Neustar's, that don't have any relationship to the originination= carrier - the termination carrier dips an independently developed database= of name-number relationships.  These databases are developed using a = wide variety of sources and have evolved to be very accurate, but hardly "authoritative".

 

And yes, Hadriel, there are regulatory restrictions,= mostly about what the NPAC (number portability database administrator) can= do. The CNAM databases have very few regulations to deal with.<= /p>

 

Brian 


On Wednesday, August 14, 2013, Hadriel Kaplan wrote:


On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:

> That's an interesting question.
> If there were a cert per phone number, then the CNAM data could be in = the cert, eliminating another retrieval.

There was some discussion around that early on.  I think there was con= cern about making the signing CAs have to verify CNAM-type info in a cert s= igning request before signing it.

If they don't perform verification that you really are the name for the pho= ne-number, then you could claim any name you wanted; if they do perform ver= ification, it's either through a manual process and very expensive (as web = certs are today), or the CA uses a CNAM database to populate the info in the cert without letting you choos= e what to put in it.

It happens to be that in the US the numbering admin contractor and the most= popular CNAM database are the same company, but my guess is there are regu= latory restrictions around how integrated they can be. (I don't know that t= o be the case, but it's just a guess that antitrust issues would make it so... but IANAL)

Regardless, it also hits pricing/charging issues.  Currently the CNAM = database providers charge the terminating side for retrieval, and I don't t= hink we want that type of model for STIR at all. (as an aside: it's always = seemed crazy to me that the terminating side pays for CNAM, rather than the opposite - I know how it came about to= be that way, but I think it's counter-productive today)


> But it seems that isn't being viewed as an attractive way to go.

I don't know what you mean by that comment?  Using certs for STIR is m= ost definitely on the table.  There're pros/cons with any proposed sol= ution thus far.  The CIDER concept has warts too.  Ultimately we'= re going to have to choose, but there's no "perfect" solution as far as I can tell.


> Otherwise, it remains yet another DB that needs to be queried.

Not necessarily.  Even with a CIDER approach one could put the CNAM in= fo in the same database, and in such a way that a single query returns both= STIR and CNAM info at the same time.  You could, for example, put it = in a NAPTR like was done in draft-ietf-enum-cnam-08, or you could put it in another TXT RR, or whatever.  Of course if you= do that then the CIDER database could not be made publicly accessible, or = at least the CNAM info record could not be made publicly accessible.

But even if the national CIDER database doesn't have the CNAM info, the loc= al database copies of it in the carriers could integrate the CNAM info into= their local copies.  That way they get to have a single query/respons= e model, even if the data comes from different sources.

-hadriel

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--_000_38726EDA2109264987B45E29E758C4D6049AA750MISOUT7MSGUSR9N_-- From pkyzivat@alum.mit.edu Wed Aug 14 07:51:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBD711E81EC for ; Wed, 14 Aug 2013 07:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.082 X-Spam-Level: X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ66o2LiCyex for ; Wed, 14 Aug 2013 07:51:45 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id D7CAD11E814C for ; Wed, 14 Aug 2013 07:51:43 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta05.westchester.pa.mail.comcast.net with comcast id CeMn1m0020cZkys55erikK; Wed, 14 Aug 2013 14:51:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Ceri1m00f3ZTu2S3WeriNV; Wed, 14 Aug 2013 14:51:42 +0000 Message-ID: <520B997D.9060809@alum.mit.edu> Date: Wed, 14 Aug 2013 16:51:41 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376491902; bh=Wc65n17etx/ueqF08MTkDh3moA8YrBYaWZqxgsdzRQI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WmEesw6/PJVHuGfGs2AQwYw+AgKhA2zauA28DKL+UbywPm6NYcTq62aJUCcy7UH54 mzBNeLFb7apKAyhUrZLQUx6Uy4GnP8uoBVeK1farHJ/B5oy1mxpk8TNzAivhL8kZUh 30+hiUu7r9OKma3I+FDOu23iGvxb/iRys/YkG68vOiTupIXZsAuu9fa38kV4ECZdZM YxkiN1/EA6VT+bnrVM3qOZtP57RUm8ZQO4X8lmfYJhdASOdUEzhO1CC1VMKvmlFKnV ZXMv33ZpLDE2a/sa9hukiQ8pHNVEVxUuL2BiBd7lmndJj1fVJytc7yXylpdrp2ojAK 7SzKxKicTkN/g== Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:51:51 -0000 I'm now convinced that CNAM should be out of scope for now, to avoid a rat hole. I can imagine that this might need to be revisited again in the future, probably as a different WG. Thanks, Paul On 8/14/13 3:31 PM, Brian Rosen wrote: > I think we probably should keep CNAM out of this for now anyway. > > The advantage of the credential delegation process as we have defined it > is that it's authoritative. > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on on > behalf of the origination carrier and queried by the termination carrier > (often with a charge to query). The content is what the carrier has > recorde from the original service order, but there isn't any attempt to > validate those names, and there are carriers who will let you put > anything you like in there. How "authoritative" is that? Then there > are other databases, like Neustar's, that don't have any relationship to > the originination carrier - the termination carrier dips an > independently developed database of name-number relationships. These > databases are developed using a wide variety of sources and have evolved > to be very accurate, but hardly "authoritative". > > And yes, Hadriel, there are regulatory restrictions, mostly about what > the NPAC (number portability database administrator) can do. The CNAM > databases have very few regulations to deal with. > > Brian > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote: > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat > wrote: > > > That's an interesting question. > > If there were a cert per phone number, then the CNAM data could > be in the cert, eliminating another retrieval. > > There was some discussion around that early on. I think there was > concern about making the signing CAs have to verify CNAM-type info > in a cert signing request before signing it. > > If they don't perform verification that you really are the name for > the phone-number, then you could claim any name you wanted; if they > do perform verification, it's either through a manual process and > very expensive (as web certs are today), or the CA uses a CNAM > database to populate the info in the cert without letting you choose > what to put in it. > > It happens to be that in the US the numbering admin contractor and > the most popular CNAM database are the same company, but my guess is > there are regulatory restrictions around how integrated they can be. > (I don't know that to be the case, but it's just a guess that > antitrust issues would make it so... but IANAL) > > Regardless, it also hits pricing/charging issues. Currently the > CNAM database providers charge the terminating side for retrieval, > and I don't think we want that type of model for STIR at all. (as an > aside: it's always seemed crazy to me that the terminating side pays > for CNAM, rather than the opposite - I know how it came about to be > that way, but I think it's counter-productive today) > > > > But it seems that isn't being viewed as an attractive way to go. > > I don't know what you mean by that comment? Using certs for STIR is > most definitely on the table. There're pros/cons with any proposed > solution thus far. The CIDER concept has warts too. Ultimately > we're going to have to choose, but there's no "perfect" solution as > far as I can tell. > > > > Otherwise, it remains yet another DB that needs to be queried. > > Not necessarily. Even with a CIDER approach one could put the CNAM > info in the same database, and in such a way that a single query > returns both STIR and CNAM info at the same time. You could, for > example, put it in a NAPTR like was done in draft-ietf-enum-cnam-08, > or you could put it in another TXT RR, or whatever. Of course if > you do that then the CIDER database could not be made publicly > accessible, or at least the CNAM info record could not be made > publicly accessible. > > But even if the national CIDER database doesn't have the CNAM info, > the local database copies of it in the carriers could integrate the > CNAM info into their local copies. That way they get to have a > single query/response model, even if the data comes from different > sources. > > -hadriel > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From richard@shockey.us Wed Aug 14 10:02:16 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8E521F9EF4 for ; Wed, 14 Aug 2013 10:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83qVIt8mq1Yv for ; Wed, 14 Aug 2013 10:02:10 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id DA68421F9AC4 for ; Wed, 14 Aug 2013 10:01:59 -0700 (PDT) Received: (qmail 8885 invoked by uid 0); 14 Aug 2013 17:01:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.mail.unifiedlayer.com with SMTP; 14 Aug 2013 17:01:34 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=88n47HCtfZYxlvrlOCzAU46qdbtXyVwddGi9El44LyU=; b=VJApksPMjIGno01kVHKPxHRsM9fzMnoKa8tynb2M/hqEVdrlOcM0DgqPP3K6zRcevRdgMCA8AgtRg3BHv26+9TfHk7VBvAuRULFX2YlPQeXCVDszEzlpblKp50Hvf3DV; Received: from [71.114.100.16] (port=49850 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V9eRx-00026N-Fm; Wed, 14 Aug 2013 11:01:33 -0600 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Brian Rosen'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <520B997D.9060809@alum.mit.edu> In-Reply-To: <520B997D.9060809@alum.mit.edu> Date: Wed, 14 Aug 2013 13:01:30 -0400 Message-ID: <00d601ce990f$eceff0f0$c6cfd2d0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAmNFLYoCnpukhgIjunD9AcypclECnwcp9wH9UiaQAehfhtMCbBHbEgHDEuIkAgFiOZEBpfjYOgJw3680l+GkGmA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org, 'Hadriel Kaplan' Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:02:16 -0000 I agree. I'll shut up now. It is a "bridge too far". I was just trying to "think out loud" on how the UA's might deal with this new class of data. CNAM itself is badly broken and nonfunctional in an all SIP world. You can return to your regularly scheduled program. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, August 14, 2013 10:52 AM To: Brian Rosen Cc: stir@ietf.org; Hadriel Kaplan Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I'm now convinced that CNAM should be out of scope for now, to avoid a rat hole. I can imagine that this might need to be revisited again in the future, probably as a different WG. Thanks, Paul On 8/14/13 3:31 PM, Brian Rosen wrote: > I think we probably should keep CNAM out of this for now anyway. > > The advantage of the credential delegation process as we have defined > it is that it's authoritative. > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on on > behalf of the origination carrier and queried by the termination > carrier (often with a charge to query). The content is what the > carrier has recorde from the original service order, but there isn't > any attempt to validate those names, and there are carriers who will > let you put anything you like in there. How "authoritative" is that? > Then there are other databases, like Neustar's, that don't have any > relationship to the originination carrier - the termination carrier > dips an independently developed database of name-number relationships. > These databases are developed using a wide variety of sources and have > evolved to be very accurate, but hardly "authoritative". > > And yes, Hadriel, there are regulatory restrictions, mostly about what > the NPAC (number portability database administrator) can do. The CNAM > databases have very few regulations to deal with. > > Brian > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote: > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat > wrote: > > > That's an interesting question. > > If there were a cert per phone number, then the CNAM data could > be in the cert, eliminating another retrieval. > > There was some discussion around that early on. I think there was > concern about making the signing CAs have to verify CNAM-type info > in a cert signing request before signing it. > > If they don't perform verification that you really are the name for > the phone-number, then you could claim any name you wanted; if they > do perform verification, it's either through a manual process and > very expensive (as web certs are today), or the CA uses a CNAM > database to populate the info in the cert without letting you choose > what to put in it. > > It happens to be that in the US the numbering admin contractor and > the most popular CNAM database are the same company, but my guess is > there are regulatory restrictions around how integrated they can be. > (I don't know that to be the case, but it's just a guess that > antitrust issues would make it so... but IANAL) > > Regardless, it also hits pricing/charging issues. Currently the > CNAM database providers charge the terminating side for retrieval, > and I don't think we want that type of model for STIR at all. (as an > aside: it's always seemed crazy to me that the terminating side pays > for CNAM, rather than the opposite - I know how it came about to be > that way, but I think it's counter-productive today) > > > > But it seems that isn't being viewed as an attractive way to go. > > I don't know what you mean by that comment? Using certs for STIR is > most definitely on the table. There're pros/cons with any proposed > solution thus far. The CIDER concept has warts too. Ultimately > we're going to have to choose, but there's no "perfect" solution as > far as I can tell. > > > > Otherwise, it remains yet another DB that needs to be queried. > > Not necessarily. Even with a CIDER approach one could put the CNAM > info in the same database, and in such a way that a single query > returns both STIR and CNAM info at the same time. You could, for > example, put it in a NAPTR like was done in draft-ietf-enum-cnam-08, > or you could put it in another TXT RR, or whatever. Of course if > you do that then the CIDER database could not be made publicly > accessible, or at least the CNAM info record could not be made > publicly accessible. > > But even if the national CIDER database doesn't have the CNAM info, > the local database copies of it in the carriers could integrate the > CNAM info into their local copies. That way they get to have a > single query/response model, even if the data comes from different > sources. > > -hadriel > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Wed Aug 14 10:50:38 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAAC21E80D9 for ; Wed, 14 Aug 2013 10:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.594 X-Spam-Level: X-Spam-Status: No, score=0.594 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr4TGgCOihFy for ; Wed, 14 Aug 2013 10:50:33 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id AC3BF21F862B for ; Wed, 14 Aug 2013 10:50:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe02.verizonbusiness.com with ESMTP; 14 Aug 2013 17:50:31 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,878,1367971200"; d="scan'208,217";a="526706899" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 14 Aug 2013 17:50:30 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Wed, 14 Aug 2013 13:50:30 -0400 To: "PFAUTZ, PENN L" , Brian Rosen , Hadriel Kaplan Date: Wed, 14 Aug 2013 13:50:28 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKnQk1tpKWU6kSXx4jFw/xpJ5mUw4pAgAA0zVA= Message-ID: <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2B0F677F0B95454297753F58D4A07FA3012AA54E2CFHDP1LUMXC7V3_" MIME-Version: 1.0 Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:50:38 -0000 --_000_2B0F677F0B95454297753F58D4A07FA3012AA54E2CFHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would it be possible to provide an indication of whether the calling name w= as validated (in the same sense that the calling number was validated, but = an independent indication)? ISTM that should be a simple exercise, protocol-wise. And it maintains the= parallel treatment of name and number that we have today (e.g., there are = today separate indications of privacy, for name and number). But that's no= t my main concern; mostly I'm thinking of the evolution of the process by w= hich calling name is provided. Even if it's not possible to validate calli= ng name as provided by CNAM, it might be possible to validate calling name = as provided by other methods; e.g., by the calling network in the display-n= ame header field in the FROM or (more likely in public networks) the P-A-ID= header. tim From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of PFA= UTZ, PENN L Sent: Wednesday, August 14, 2013 9:37 AM To: Brian Rosen; Hadriel Kaplan Cc: stir@ietf.org; Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I assume the concern in this thread is with the case where a number might b= e authenticated but the CNAM displayed would be misleading because of lax p= olicies of the CNAM provider - e.g., the bad guy makes a call from what is = indeed his legit number but has managed to get Bank of America into his CNA= M entry. I'm thinking that taking on CNAM in the ietf may be a bridge too far for st= ir. Leave what happens after the number is validated up to national authori= ties since arrangements may differ. And at least in the case above it shoul= d be possible to trace back to the perp. More generally I think the object of stir ought to be just to provide the c= ustomer an indication of whether the calling number was validated on not - = whether calls get blocked or unvalidated numbers are still displayed should= be up to the customer and their service provider. Penn Pfautz AT&T Access Management +1-732-420-4962 From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, August 14, 2013 9:32 AM To: Hadriel Kaplan Cc: stir@ietf.org; Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I think we probably should keep CNAM out of this for now anyway. The advantage of the credential delegation process as we have defined it is= that it's authoritative. The current CNAM databases cannot be called "authoritative" really. Classi= cally, as you describe, there is a database operated by on on behalf of the= origination carrier and queried by the termination carrier (often with a c= harge to query). The content is what the carrier has recorde from the orig= inal service order, but there isn't any attempt to validate those names, an= d there are carriers who will let you put anything you like in there. How = "authoritative" is that? Then there are other databases, like Neustar's, t= hat don't have any relationship to the originination carrier - the terminat= ion carrier dips an independently developed database of name-number relatio= nships. These databases are developed using a wide variety of sources and = have evolved to be very accurate, but hardly "authoritative". And yes, Hadriel, there are regulatory restrictions, mostly about what the = NPAC (number portability database administrator) can do. The CNAM databases= have very few regulations to deal with. Brian On Wednesday, August 14, 2013, Hadriel Kaplan wrote: On Aug 13, 2013, at 10:20 PM, Paul Kyzivat > wrote: > That's an interesting question. > If there were a cert per phone number, then the CNAM data could be in the= cert, eliminating another retrieval. There was some discussion around that early on. I think there was concern = about making the signing CAs have to verify CNAM-type info in a cert signin= g request before signing it. If they don't perform verification that you really are the name for the pho= ne-number, then you could claim any name you wanted; if they do perform ver= ification, it's either through a manual process and very expensive (as web = certs are today), or the CA uses a CNAM database to populate the info in th= e cert without letting you choose what to put in it. It happens to be that in the US the numbering admin contractor and the most= popular CNAM database are the same company, but my guess is there are regu= latory restrictions around how integrated they can be. (I don't know that t= o be the case, but it's just a guess that antitrust issues would make it so= ... but IANAL) Regardless, it also hits pricing/charging issues. Currently the CNAM datab= ase providers charge the terminating side for retrieval, and I don't think = we want that type of model for STIR at all. (as an aside: it's always seeme= d crazy to me that the terminating side pays for CNAM, rather than the oppo= site - I know how it came about to be that way, but I think it's counter-pr= oductive today) > But it seems that isn't being viewed as an attractive way to go. I don't know what you mean by that comment? Using certs for STIR is most d= efinitely on the table. There're pros/cons with any proposed solution thus= far. The CIDER concept has warts too. Ultimately we're going to have to = choose, but there's no "perfect" solution as far as I can tell. > Otherwise, it remains yet another DB that needs to be queried. Not necessarily. Even with a CIDER approach one could put the CNAM info in= the same database, and in such a way that a single query returns both STIR= and CNAM info at the same time. You could, for example, put it in a NAPTR= like was done in draft-ietf-enum-cnam-08, or you could put it in another T= XT RR, or whatever. Of course if you do that then the CIDER database could= not be made publicly accessible, or at least the CNAM info record could no= t be made publicly accessible. But even if the national CIDER database doesn't have the CNAM info, the loc= al database copies of it in the carriers could integrate the CNAM info into= their local copies. That way they get to have a single query/response mod= el, even if the data comes from different sources. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_2B0F677F0B95454297753F58D4A07FA3012AA54E2CFHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would it be possible to pr= ovide an indication of whether the calling name was validated (in the same = sense that the calling number was validated, but an independent indication)= ?

 

IS= TM that should be a simple exercise, protocol-wise.  And it maintains = the parallel treatment of name and number that we have today (e.g., there a= re today separate indications of privacy, for name and number).  But t= hat’s not my main concern; mostly I’m thinking of the evolution= of the process by which calling name is provided.  Even if it’s= not possible to validate calling name as provided by CNAM, it might be pos= sible to validate calling name as provided by other methods; e.g., by the c= alling network in the display-name header field in the FROM or (more likely= in public networks) the P-A-ID header.

 

tim

 

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf= .org] On Behalf Of PFAUTZ, PENN L
Sent: Wednesday, August = 14, 2013 9:37 AM
To: Brian Rosen; Hadriel Kaplan
Cc: st= ir@ietf.org; Paul Kyzivat
Subject: Re: [stir] Early Homework (was= Re: Moving from BOF to Charter)

 

I assume the = concern in this thread is with the case where a number might be authenticat= ed but the CNAM displayed would be misleading because of lax policies of th= e CNAM provider – e.g., the bad guy makes a call from what is indeed = his legit number but has managed to get Bank of America into his CNAM entry= .

 =

I’m thinking that taking on CNAM in t= he ietf may be a bridge too far for stir. Leave what happens after the numb= er is validated up to national authorities since arrangements may differ. A= nd at least in the case above it should be possible to trace back to the pe= rp.

 

More generally I think the object of stir= ought to be just to provide the customer an indication of whether the call= ing number was validated on not – whether calls get blocked or unvali= dated numbers are still displayed should be up to the customer and their se= rvice provider.

 = ;

Penn Pfautz

AT&= ;T Access Management=

+1-732-420-4962

From: sti= r-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Wed= nesday, August 14, 2013 9:32 AM
To: Hadriel Kaplan
Cc: = stir@ietf.org; Paul Kyzivat
Subj= ect: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

 

I think we probably should keep CNAM out of this for now anyway.=

 

The advantage of the credential delegation process as we have= defined it is that it's authoritative.

 

The curre= nt CNAM databases cannot be called "authoritative" really.  = Classically, as you describe, there is a database operated by on on be= half of the origination carrier and queried by the termination carrier (oft= en with a charge to query).  The content is what the carrier= has recorde from the original service order, but there isn't any atte= mpt to validate those names, and there are carriers who will let you put an= ything you like in there.  How "authoritative" is that? &nbs= p;Then there are other databases, like Neustar's, that don't have any = relationship to the originination carrier - the termination carrier dips an= independently developed database of name-number relationships.  These= databases are developed using a wide variety of sources and have evolved t= o be very accurate, but hardly "authoritative".

 

And yes, Hadriel, there are regulatory restrictions, mostly about wh= at the NPAC (number portability database administrator) can do. The CNAM da= tabases have very few regulations to deal with.

 

Bri= an 


On Wednesda= y, August 14, 2013, Hadriel Kaplan wrote:


On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> That's an interesting q= uestion.
> If there were a cert per phone number, then the CNAM data = could be in the cert, eliminating another retrieval.

There was some = discussion around that early on.  I think there was concern about maki= ng the signing CAs have to verify CNAM-type info in a cert signing request = before signing it.

If they don't perform verification that you reall= y are the name for the phone-number, then you could claim any name you want= ed; if they do perform verification, it's either through a manual process a= nd very expensive (as web certs are today), or the CA uses a CNAM database = to populate the info in the cert without letting you choose what to put in = it.

It happens to be that in the US the numbering admin contractor a= nd the most popular CNAM database are the same company, but my guess is the= re are regulatory restrictions around how integrated they can be. (I don't = know that to be the case, but it's just a guess that antitrust issues would= make it so... but IANAL)

Regardless, it also hits pricing/charging = issues.  Currently the CNAM database providers charge the terminating = side for retrieval, and I don't think we want that type of model for STIR a= t all. (as an aside: it's always seemed crazy to me that the terminating si= de pays for CNAM, rather than the opposite - I know how it came about to be= that way, but I think it's counter-productive today)


> But i= t seems that isn't being viewed as an attractive way to go.

I don't = know what you mean by that comment?  Using certs for STIR is most defi= nitely on the table.  There're pros/cons with any proposed solution th= us far.  The CIDER concept has warts too.  Ultimately we're going= to have to choose, but there's no "perfect" solution as far as I= can tell.


> Otherwise, it remains yet another DB that needs = to be queried.

Not necessarily.  Even with a CIDER approach one= could put the CNAM info in the same database, and in such a way that a sin= gle query returns both STIR and CNAM info at the same time.  You could= , for example, put it in a NAPTR like was done in draft-ietf-enum-cnam-08, = or you could put it in another TXT RR, or whatever.  Of course if you = do that then the CIDER database could not be made publicly accessible, or a= t least the CNAM info record could not be made publicly accessible.

= But even if the national CIDER database doesn't have the CNAM info, the loc= al database copies of it in the carriers could integrate the CNAM info into= their local copies.  That way they get to have a single query/respons= e model, even if the data comes from different sources.

-hadriel
=
_______________________________________________
stir mailing liststir@ietf.org
https://www.ietf.org/mailman/l= istinfo/stir

= --_000_2B0F677F0B95454297753F58D4A07FA3012AA54E2CFHDP1LUMXC7V3_-- From br@brianrosen.net Wed Aug 14 11:38:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCBB21E80BB for ; Wed, 14 Aug 2013 11:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.384 X-Spam-Level: X-Spam-Status: No, score=-99.384 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctwShuTL8SXp for ; Wed, 14 Aug 2013 11:38:14 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id C2FF521E80B6 for ; Wed, 14 Aug 2013 11:38:13 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id lb1so10365182pab.26 for ; Wed, 14 Aug 2013 11:38:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5GNL9iWiv3Ed9/UjmCi/xkM1H4Ytwv3jiIa8gSy4VCQ=; b=g2gftg8gI/A4KzQfZs2jijR6HyA0+60P+Y9LE37KZXvSX5dYm2ZPS+uyk0XPtrC2kL 7M5kgBwc4wpyzEf+ibsNnlfqbUzoWPQd/U+ryjjDeb3pndIgnAsLSwgCZrXsW2f4xwOH nbLud/uW03Xh1l3DIJYiZu58m1EyUEZPA0mdTxqyWAAs4dTFEIccaVu5ENfxh8K5uSfD 2IVBXLYhp6ujGLbyRkQ1zpyf63JWVDHqg6gddhE36J3kAKcx3wq+vTSLTf4zL042uEfd 6EhXK9vz7GFMgfwkqsoh5pC+iKCtWSBASJdA/wfTT2KsHqKPCdWOmh1yrnWvA6uBgbB2 ZeGA== X-Gm-Message-State: ALoCoQny7jQ8ZasqVLP5/6M1apPUaUmcDtfGrDgMKvKSht1uW6BNAp9uSUsaVa8CoyGvbQy4/ChW MIME-Version: 1.0 X-Received: by 10.68.12.97 with SMTP id x1mr4200627pbb.150.1376505492556; Wed, 14 Aug 2013 11:38:12 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Wed, 14 Aug 2013 11:38:12 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> Date: Wed, 14 Aug 2013 14:38:12 -0400 Message-ID: From: Brian Rosen To: "Dwight, Timothy M (Tim)" Content-Type: multipart/alternative; boundary=bcaec5215f91ea685b04e3eca84c Cc: "stir@ietf.org" , Hadriel Kaplan , "PFAUTZ, PENN L" , Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 18:38:23 -0000 --bcaec5215f91ea685b04e3eca84c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I suppose it's possible, but what is the criteria for validation? With TNs, we have credentials that accompany number delegation - we have a clear path to assuring that the caller asserting the identity is indeed entitled to claim control of that number (well, SPs mostly, not the caller, at least initially). There is no equivalent assurance for CNAM. I don't want to get into a fight over which database is better, but the alternate, doesn't depend on the origination carrier mechansism is statisically actually a better "validation" of the content than what a traditional carrier gets in his service order (because they usually don't actually validate the content), and is infiniately better than the carriers that allow the consumer to put anything they want in the database. Without a reasonable way to assure that the database is actually valid, what is the value of carrying an assertion? If we had such a mechanism, what prevents one of the carriers that let's you put anything you want in the database from asserting that the content of P-A-ID is valid, when the user is allowed to say whatever they want goes in P-A-ID? The best thing I can come up with would be to have some independent validation service that used other data sources to validate the content, and let them sign it. Then we could carry that signature somewhere. Right now, I think we should leave it out of scope. If we can figure out a way to do validation, then we can revisit the notion of carrying evidence of validation in future work. Does argue for making sure that whatever mechanism we arrive at should have some obvious extension mechanism, perhaps along the lines of what Jon was suggesting for media properties. If you recall, he proposed to have a digest of SDP where the digest was protected by the signature, but if the SDP received didn't match the SDP sent, the termination side could know that, but the basic identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP). Brian On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > Would it be possible to provide an indication of whether the calling name > was validated (in the same sense that the calling number was validated, b= ut > an independent indication)?**** > > ** ** > > ISTM that should be a simple exercise, protocol-wise. And it maintains > the parallel treatment of name and number that we have today (e.g., there > are today separate indications of privacy, for name and number). But > that=92s not my main concern; mostly I=92m thinking of the evolution of t= he > process by which calling name is provided. Even if it=92s not possible t= o > validate calling name as provided by CNAM, it might be possible to valida= te > calling name as provided by other methods; e.g., by the calling network i= n > the display-name header field in the FROM or (more likely in public > networks) the P-A-ID header.**** > > ** ** > > tim**** > > ** ** > > ** ** > > *From:* stir-bounces@ietf.org 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org] > *On Behalf Of *PFAUTZ, PENN L > *Sent:* Wednesday, August 14, 2013 9:37 AM > *To:* Brian Rosen; Hadriel Kaplan > *Cc:* stir@ietf.org ; Paul > Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to Charter)= * > *** > > ** ** > > I assume the concern in this thread is with the case where a number might > be authenticated but the CNAM displayed would be misleading because of la= x > policies of the CNAM provider =96 e.g., the bad guy makes a call from wha= t is > indeed his legit number but has managed to get Bank of America into his > CNAM entry.**** > > ** ** > > I=92m thinking that taking on CNAM in the ietf may be a bridge too far fo= r > stir. Leave what happens after the number is validated up to national > authorities since arrangements may differ. And at least in the case above > it should be possible to trace back to the perp.**** > > ** ** > > More generally I think the object of stir ought to be just to provide the > customer an indication of whether the calling number was validated on not= =96 > whether calls get blocked or unvalidated numbers are still displayed shou= ld > be up to the customer and their service provider.**** > > ** ** > > Penn Pfautz**** > > AT&T Access Management**** > > +1-732-420-4962**** > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf > Of *Brian Rosen > *Sent:* Wednesday, August 14, 2013 9:32 AM > *To:* Hadriel Kaplan > *Cc:* stir@ietf.org; Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to Charter)= * > *** > > ** ** > > I think we probably should keep CNAM out of this for now anyway.**** > > ** ** > > The advantage of the credential delegation process as we have defined it > is that it's authoritative.**** > > ** ** > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on on beha= lf > of the origination carrier and queried by the termination carrier (often > with a charge to query). The content is what the carrier has recorde fro= m > the original service order, but there isn't any attempt to validate those > names, and there are carriers who will let you put anything you like in > there. How "authoritative" is that? Then there are other databases, lik= e > Neustar's, that don't have any relationship to the originination carrier = - > the termination carrier dips an independently developed database of > name-number relationships. These databases are developed using a wide > variety of sources and have evolved to be very accurate, but hardly > "authoritative".**** > > ** ** > > And yes, Hadriel, there are regulatory restrictions, mostly about what th= e > NPAC (number portability database administrator) can do. The CNAM databas= es > have very few regulations to deal with.**** > > ** ** > > Brian **** > > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote:**** > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat --bcaec5215f91ea685b04e3eca84c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I suppose it's possible, but what is the criteria for validation?
<= br>
With TNs, we have credentials that accompany number delegatio= n - we have a clear path to assuring that the caller asserting the identity= is indeed entitled to claim control of that number (well, SPs mostly, not = the caller, at least initially). =A0There is no equivalent assurance for CN= AM. =A0

I don't want to get into a fight over which databas= e is better, but the alternate, doesn't depend on the origination carri= er mechansism=A0is statisically actually a better "validation" of= the content than what a traditional carrier gets in his service order (bec= ause they usually don't actually validate the content), and is infiniat= ely better than the carriers that allow the consumer to put anything they w= ant in the database. =A0Without a reasonable way to assure that the databas= e is actually valid, what is the value of carrying an assertion?

If we had such a mechanism, what prevents one of the ca= rriers that let's you put anything you want in the database from assert= ing that the content of P-A-ID is valid, when the user is allowed to say wh= atever they want goes in P-A-ID?

The best thing I can come up with would be to have some= independent validation service that used other data sources to validate th= e content, and let them sign it. =A0Then we could carry that signature some= where.=A0

Right now, I think we should leave it out of scope. =A0= If we can figure out a way to do validation, then we can revisit the notion= of carrying evidence of validation in future work.

Does argue for making sure that whatever mechanism we arrive at should have= some obvious extension mechanism, perhaps along the lines of what Jon was = suggesting for media properties. =A0If you recall, he proposed to have a di= gest of SDP where the digest was protected by the signature, but if the SDP= received didn't match the SDP sent, the termination side could know th= at, but the basic identity mechanism could=A0succeed anyway (t= hat is, you knew you had a valid identity and a modified SDP).

Brian

On Wednesday, August 14, 2013, Dwight, Ti= mothy M (Tim) wrote:

Would it be possible to provide an in= dication of whether the calling name was validated (in the same sense that = the calling number was validated, but an independent indication)?=

=A0

ISTM that should be a simple exercise, protocol-wise.=A0= And it maintains the parallel treatment of name and number that we have to= day (e.g., there are today separate indications of privacy, for name and nu= mber).=A0 But that=92s not my main concern; mostly I=92m thinking of the ev= olution of the process by which calling name is provided.=A0 Even if it=92s= not possible to validate calling name as provided by CNAM, it might be pos= sible to validate calling name as provided by other methods; e.g., by the c= alling network in the display-name header field in the FROM or (more likely= in public networks) the P-A-ID header.

=A0

tim

=A0

=A0

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Wednesday, August 14, 2013 9:37 AM
To: Brian Rosen; = Hadriel Kaplan
Cc: stir@ietf.org; Paul Kyzivat=
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Chart= er)

=A0

I assume the concern in this thread is with the case whe= re a number might be authenticated but the CNAM displayed would be misleadi= ng because of lax policies of the CNAM provider =96 e.g., the bad guy makes= a call from what is indeed his legit number but has managed to get Bank of= America into his CNAM entry.

=A0

I=92m thinking that taking on CNAM in the ietf may be a bridge= too far for stir. Leave what happens after the number is validated up to n= ational authorities since arrangements may differ. And at least in the case= above it should be possible to trace back to the perp.

=A0

More generally I think the object of stir ought to be just to = provide the customer an indication of whether the calling number was valida= ted on not =96 whether calls get blocked or unvalidated numbers are still d= isplayed should be up to the customer and their service provider.=

=A0

Penn Pfautz

AT&T Access Management

+1-732= -420-4962

From: stir-bounces@ietf.org= [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Wednesday, August 14, 2013 9:32 AM
To: Hadriel Kapla= n
Cc: stir@ietf.org; Paul Kyzivat
Subject: Re: [= stir] Early Homework (was Re: Moving from BOF to Charter)

=A0

I think we probably should keep CNAM out of this= for now anyway.

=A0

<= p>The advantage of the credential delegation process as we have defined it = is that it's authoritative.

=A0

The current CNAM databases= cannot be called "authoritative" really. =A0Classically, as you = describe,=A0there is a database operated by on on behalf of the origination= carrier and queried by the termination carrier (often with=A0a charge to q= uery). =A0The content is=A0what the carrier has recorde from the original s= ervice order,=A0but there isn't any attempt to validate those names, an= d there are carriers who will let you put anything you like in there. =A0Ho= w "authoritative" is that? =A0Then there are other databases, lik= e Neustar's,=A0that don't have any relationship to the origininatio= n carrier - the termination carrier dips an independently developed databas= e of name-number relationships. =A0These databases are developed using a wi= de variety of sources and have evolved to be very accurate, but hardly &quo= t;authoritative".

=A0

And yes, Hadriel, there ar= e regulatory restrictions, mostly about what the NPAC (number portability d= atabase administrator) can do. The CNAM databases have very few regulations= to deal with.

=A0

Brian=A0

=


On Wednesday, August 14, 2013, Hadriel Kaplan wrote:=


On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <= pk

--bcaec5215f91ea685b04e3eca84c-- From pkyzivat@alum.mit.edu Wed Aug 14 12:03:52 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3448E11E81FE for ; Wed, 14 Aug 2013 12:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaRShFvZTyCo for ; Wed, 14 Aug 2013 12:03:46 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 41A1D11E819E for ; Wed, 14 Aug 2013 12:03:46 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id Ch9c1m0030vyq2s53j3lR2; Wed, 14 Aug 2013 19:03:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Cj3l1m00M3ZTu2S3Rj3lNr; Wed, 14 Aug 2013 19:03:45 +0000 Message-ID: <520BD490.4000701@alum.mit.edu> Date: Wed, 14 Aug 2013 21:03:44 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376507025; bh=JZf7EWtGjlo4YRMu5tmgj2cwFnG0CmHfC5JRjM1PI1o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Kg+ybEw8JuPpsFgorVOzgzk4Gyk3+DOGW9u4GCp+ysADzzT0z86lhLmzgSoQxo/XG O5jET8mgGt0vq7IDKrt4qrGhQdV3Hn7Aqv/D/PrDc6IliHb9XxD+91/MV2/mpLOztq s4dTm1HxssCEBe2g4SX/mAnq19Qi7FuFUw7mu8+9eJsfPhfT1wtkG8n0uWVVQxfn+s PGlGUIN3Kzze3mcS3vfKpvRKr2A6qwn+hHg06bdty5CYtW3BxzCgEm2D+tRgoyBezT d9D3XJMBKo8q9OOZDiAiR7MVSwle59ZELVJ8IcSWS8V3jIgDDBdhOtlECT51ASQvI6 mDMBvqX1JfYmw== Cc: "stir@ietf.org" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , "PFAUTZ, PENN L" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 19:03:52 -0000 On 8/14/13 8:38 PM, Brian Rosen wrote: > I suppose it's possible, but what is the criteria for validation? > > With TNs, we have credentials that accompany number delegation - we have > a clear path to assuring that the caller asserting the identity is > indeed entitled to claim control of that number (well, SPs mostly, not > the caller, at least initially). There is no equivalent assurance for > CNAM. > > I don't want to get into a fight over which database is better, but the > alternate, doesn't depend on the origination carrier mechansism is > statisically actually a better "validation" of the content than what a > traditional carrier gets in his service order (because they usually > don't actually validate the content), and is infiniately better than the > carriers that allow the consumer to put anything they want in the > database. Without a reasonable way to assure that the database is > actually valid, what is the value of carrying an assertion? While I recognize that letting the customer put in whatever they want is problematic, I have no idea whether the alternative of letting the CNAM provider include whatever they want is "better". (How would we measure that?) (I've just been trying to deal with an "information aggregator" that is publishing wrong information about me and won't change it. So I'm not feeling good about that sort of thing.) ISTM that is is yet another example of ancient, informal, manual systems, that once mostly "worked" based on the good will of the people involved, but that have now been automated into monstrosities that nobody understands. (Management of healthcare data is another example.) Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws. Alternatively this could be left to the open market. (E.g., The callee could just Google the calling number.) In any case STIR can't go down this rat hole. Thanks, Paul > If we had such a mechanism, what prevents one of the carriers that let's > you put anything you want in the database from asserting that the > content of P-A-ID is valid, when the user is allowed to say whatever > they want goes in P-A-ID? > > The best thing I can come up with would be to have some independent > validation service that used other data sources to validate the content, > and let them sign it. Then we could carry that signature somewhere. > > Right now, I think we should leave it out of scope. If we can figure > out a way to do validation, then we can revisit the notion of carrying > evidence of validation in future work. > > Does argue for making sure that whatever mechanism we arrive at should > have some obvious extension mechanism, perhaps along the lines of what > Jon was suggesting for media properties. If you recall, he proposed to > have a digest of SDP where the digest was protected by the signature, > but if the SDP received didn't match the SDP sent, the termination side > could know that, but the basic identity mechanism could succeed anyway > (that is, you knew you had a valid identity and a modified SDP). > > Brian > > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > > Would it be possible to provide an indication of whether the calling > name was validated (in the same sense that the calling number was > validated, but an independent indication)?____ > > __ __ > > ISTM that should be a simple exercise, protocol-wise. And it > maintains the parallel treatment of name and number that we have > today (e.g., there are today separate indications of privacy, for > name and number). But that’s not my main concern; mostly I’m > thinking of the evolution of the process by which calling name is > provided. Even if it’s not possible to validate calling name as > provided by CNAM, it might be possible to validate calling name as > provided by other methods; e.g., by the calling network in the > display-name header field in the FROM or (more likely in public > networks) the P-A-ID header.____ > > __ __ > > tim____ > > __ __ > > __ __ > > *From:*stir-bounces@ietf.org 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org > ] *On Behalf Of > *PFAUTZ, PENN L > *Sent:* Wednesday, August 14, 2013 9:37 AM > *To:* Brian Rosen; Hadriel Kaplan > *Cc:* stir@ietf.org ; > Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I assume the concern in this thread is with the case where a number > might be authenticated but the CNAM displayed would be misleading > because of lax policies of the CNAM provider – e.g., the bad guy > makes a call from what is indeed his legit number but has managed to > get Bank of America into his CNAM entry.____ > > __ __ > > I’m thinking that taking on CNAM in the ietf may be a bridge too far > for stir. Leave what happens after the number is validated up to > national authorities since arrangements may differ. And at least in > the case above it should be possible to trace back to the perp.____ > > __ __ > > More generally I think the object of stir ought to be just to > provide the customer an indication of whether the calling number was > validated on not – whether calls get blocked or unvalidated numbers > are still displayed should be up to the customer and their service > provider.____ > > __ __ > > Penn Pfautz____ > > AT&T Access Management____ > > +1-732-420-4962____ > > *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On > Behalf Of *Brian Rosen > *Sent:* Wednesday, August 14, 2013 9:32 AM > *To:* Hadriel Kaplan > *Cc:* stir@ietf.org; Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I think we probably should keep CNAM out of this for now anyway.____ > > __ __ > > The advantage of the credential delegation process as we have > defined it is that it's authoritative.____ > > __ __ > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on > on behalf of the origination carrier and queried by the termination > carrier (often with a charge to query). The content is what the > carrier has recorde from the original service order, but there isn't > any attempt to validate those names, and there are carriers who will > let you put anything you like in there. How "authoritative" is > that? Then there are other databases, like Neustar's, that don't > have any relationship to the originination carrier - the termination > carrier dips an independently developed database of name-number > relationships. These databases are developed using a wide variety > of sources and have evolved to be very accurate, but hardly > "authoritative".____ > > __ __ > > And yes, Hadriel, there are regulatory restrictions, mostly about > what the NPAC (number portability database administrator) can do. > The CNAM databases have very few regulations to deal with.____ > > __ __ > > Brian ____ > > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat From hadriel.kaplan@oracle.com Wed Aug 14 12:13:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B56911E8198 for ; Wed, 14 Aug 2013 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXLDRKpZC+CG for ; Wed, 14 Aug 2013 12:13:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9951C21F9E6E for ; Wed, 14 Aug 2013 12:13:45 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7EJDcus006536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Aug 2013 19:13:40 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EJDaqM019000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 19:13:36 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EJDa8A026436; Wed, 14 Aug 2013 19:13:36 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Aug 2013 12:13:35 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 14 Aug 2013 15:13:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <287AA00B-357C-4625-9C38-0C8A3AC6D715@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 19:13:51 -0000 I don't think we can solve that problem. A different problem, which may = be what Tim was getting at, is how a SIP endpoint receiving a message = knows whether its local SIP Service Provider believes the calling-name = is accurate or not. In other words, suppose your SSP did use a CNAM database that was = reasonably accurate, and even used a STIR-validated number to get the = info from the CNAM DB. When you receive an INVITE, which message header = field do you use for calling-name display, and how do you know it was = populated by your SSP based on STIR-validated information? Today, the answer is basically that you trust your SSP to get it right; = and the field a lot of folks use is the display-name portion of the = From, or the display-name portion of the PAI if it's there. The same can be said for the source identity calling number, in terms of = what today's behavior is. And even when this STIR thing gets deployed, = there's no indication in SIP that your SSP actually performed STIR = validation. The assumption is it did perform it, and if the validation = failed it would change the =46rom to be 'sip:unknown@unknown.invalid' or = 'sip:invalid@invalid' or whatever.[1] -hadriel [1] I'm not saying we shouldn't be more explicit in this behavior in our = docs once we get a WG, but right now it's undefined. On Aug 14, 2013, at 2:38 PM, Brian Rosen wrote: > I suppose it's possible, but what is the criteria for validation? >=20 > With TNs, we have credentials that accompany number delegation - we = have a clear path to assuring that the caller asserting the identity is = indeed entitled to claim control of that number (well, SPs mostly, not = the caller, at least initially). There is no equivalent assurance for = CNAM. =20 >=20 > I don't want to get into a fight over which database is better, but = the alternate, doesn't depend on the origination carrier mechansism is = statisically actually a better "validation" of the content than what a = traditional carrier gets in his service order (because they usually = don't actually validate the content), and is infiniately better than the = carriers that allow the consumer to put anything they want in the = database. Without a reasonable way to assure that the database is = actually valid, what is the value of carrying an assertion? >=20 > If we had such a mechanism, what prevents one of the carriers that = let's you put anything you want in the database from asserting that the = content of P-A-ID is valid, when the user is allowed to say whatever = they want goes in P-A-ID? >=20 > The best thing I can come up with would be to have some independent = validation service that used other data sources to validate the content, = and let them sign it. Then we could carry that signature somewhere.=20 >=20 > Right now, I think we should leave it out of scope. If we can figure = out a way to do validation, then we can revisit the notion of carrying = evidence of validation in future work. >=20 > Does argue for making sure that whatever mechanism we arrive at should = have some obvious extension mechanism, perhaps along the lines of what = Jon was suggesting for media properties. If you recall, he proposed to = have a digest of SDP where the digest was protected by the signature, = but if the SDP received didn't match the SDP sent, the termination side = could know that, but the basic identity mechanism could succeed anyway = (that is, you knew you had a valid identity and a modified SDP). >=20 > Brian >=20 > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > Would it be possible to provide an indication of whether the calling = name was validated (in the same sense that the calling number was = validated, but an independent indication)? >=20 > =20 >=20 > ISTM that should be a simple exercise, protocol-wise. And it = maintains the parallel treatment of name and number that we have today = (e.g., there are today separate indications of privacy, for name and = number). But that=92s not my main concern; mostly I=92m thinking of the = evolution of the process by which calling name is provided. Even if = it=92s not possible to validate calling name as provided by CNAM, it = might be possible to validate calling name as provided by other methods; = e.g., by the calling network in the display-name header field in the = FROM or (more likely in public networks) the P-A-ID header. >=20 > =20 >=20 > tim >=20 > =20 >=20 > =20 >=20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of PFAUTZ, PENN L > Sent: Wednesday, August 14, 2013 9:37 AM > To: Brian Rosen; Hadriel Kaplan > Cc: stir@ietf.org; Paul Kyzivat > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) >=20 > =20 >=20 > I assume the concern in this thread is with the case where a number = might be authenticated but the CNAM displayed would be misleading = because of lax policies of the CNAM provider =96 e.g., the bad guy makes = a call from what is indeed his legit number but has managed to get Bank = of America into his CNAM entry. >=20 > =20 >=20 > I=92m thinking that taking on CNAM in the ietf may be a bridge too far = for stir. Leave what happens after the number is validated up to = national authorities since arrangements may differ. And at least in the = case above it should be possible to trace back to the perp. >=20 > =20 >=20 > More generally I think the object of stir ought to be just to provide = the customer an indication of whether the calling number was validated = on not =96 whether calls get blocked or unvalidated numbers are still = displayed should be up to the customer and their service provider. >=20 > =20 >=20 > Penn Pfautz >=20 > AT&T Access Management >=20 > +1-732-420-4962 >=20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Wednesday, August 14, 2013 9:32 AM > To: Hadriel Kaplan > Cc: stir@ietf.org; Paul Kyzivat > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) >=20 > =20 >=20 > I think we probably should keep CNAM out of this for now anyway. >=20 > =20 >=20 > The advantage of the credential delegation process as we have defined = it is that it's authoritative. >=20 > =20 >=20 > The current CNAM databases cannot be called "authoritative" really. = Classically, as you describe, there is a database operated by on on = behalf of the origination carrier and queried by the termination carrier = (often with a charge to query). The content is what the carrier has = recorde from the original service order, but there isn't any attempt to = validate those names, and there are carriers who will let you put = anything you like in there. How "authoritative" is that? Then there = are other databases, like Neustar's, that don't have any relationship to = the originination carrier - the termination carrier dips an = independently developed database of name-number relationships. These = databases are developed using a wide variety of sources and have evolved = to be very accurate, but hardly "authoritative". >=20 > =20 >=20 > And yes, Hadriel, there are regulatory restrictions, mostly about what = the NPAC (number portability database administrator) can do. The CNAM = databases have very few regulations to deal with. >=20 > =20 >=20 > Brian=20 >=20 >=20 > On Wednesday, August 14, 2013, Hadriel Kaplan wrote: >=20 >=20 > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Wed Aug 14 12:19:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E9E21F9CC6 for ; Wed, 14 Aug 2013 12:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5Z5QDEkKh8j for ; Wed, 14 Aug 2013 12:19:12 -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 AC52911E81A4 for ; Wed, 14 Aug 2013 12:19:08 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Paul Kyzivat' , Brian Rosen Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbA= Date: Wed, 14 Aug 2013 19:19:06 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> In-Reply-To: <520BD490.4000701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 19:19:16 -0000 Just piling on... There are at least three levels of information here, maki= ng it difficult to do that within the signaling framework: * the name of the person calling (vs. the subscriber name) * the name of the organization * properties of the organization ("licensed plumber", "FDIC-insured bank", = "located in Washington, DC", "registered charity") This is more whois-like information than just the SIP display name. In the = certificate space, we have two levels: (1) assertion of domain name control= ; (2) EV (extended validation) certs. It would be interesting to see how we= ll the EV concept has worked out in practice. I don't see how signing helps here at all, for the reasons mentioned. Nefar= ious actors can use services such as http://www.callerid4u.com/ to use a le= gitimate number with just about any name string. And for corporate accounts= , the service provider has no way of knowing whether Tom Sawyer is really a= t a particular number in a range and whether that entity prefers to list th= e name of the person, just the organization, the location ("PizzaHut Leonia= ") or something else. Indeed, the same number can legitimately have multipl= e display names that change quickly over time (e.g., staff at the doctor's = office). Verifiable whois-like information could be very useful and service provider= s could see that as an opportunity, given that they do know a lot about the= ir customers, such as their billing and service address and how long they h= ave been in business. But it's a separate problem, probably more closely re= lated to the number allocation problem. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Wednesday, August 14, 2013 3:04 PM To: Brian Rosen Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On 8/14/13 8:38 PM, Brian Rosen wrote: > I suppose it's possible, but what is the criteria for validation? > > With TNs, we have credentials that accompany number delegation - we=20 > have a clear path to assuring that the caller asserting the identity=20 > is indeed entitled to claim control of that number (well, SPs mostly,=20 > not the caller, at least initially). There is no equivalent assurance=20 > for CNAM. > > I don't want to get into a fight over which database is better, but=20 > the alternate, doesn't depend on the origination carrier mechansism is=20 > statisically actually a better "validation" of the content than what a=20 > traditional carrier gets in his service order (because they usually=20 > don't actually validate the content), and is infiniately better than=20 > the carriers that allow the consumer to put anything they want in the=20 > database. Without a reasonable way to assure that the database is=20 > actually valid, what is the value of carrying an assertion? While I recognize that letting the customer put in whatever they want is pr= oblematic, I have no idea whether the alternative of letting the CNAM provi= der include whatever they want is "better". (How would we measure that?) (I've just been trying to deal with an "information aggregator" that is pub= lishing wrong information about me and won't change it. So I'm not feeling = good about that sort of thing.) ISTM that is is yet another example of ancient, informal, manual systems, t= hat once mostly "worked" based on the good will of the people involved, but= that have now been automated into monstrosities that nobody understands. (= Management of healthcare data is another example.) Ultimately there will need to be a big effort to develop a formal framework= for this. And it will probably require the creation of new laws. Alternatively this could be left to the open market. (E.g., The callee coul= d just Google the calling number.) In any case STIR can't go down this rat hole. Thanks, Paul > If we had such a mechanism, what prevents one of the carriers that=20 > let's you put anything you want in the database from asserting that=20 > the content of P-A-ID is valid, when the user is allowed to say=20 > whatever they want goes in P-A-ID? > > The best thing I can come up with would be to have some independent=20 > validation service that used other data sources to validate the=20 > content, and let them sign it. Then we could carry that signature somewh= ere. > > Right now, I think we should leave it out of scope. If we can figure=20 > out a way to do validation, then we can revisit the notion of carrying=20 > evidence of validation in future work. > > Does argue for making sure that whatever mechanism we arrive at should=20 > have some obvious extension mechanism, perhaps along the lines of what=20 > Jon was suggesting for media properties. If you recall, he proposed=20 > to have a digest of SDP where the digest was protected by the=20 > signature, but if the SDP received didn't match the SDP sent, the=20 > termination side could know that, but the basic identity mechanism=20 > could succeed anyway (that is, you knew you had a valid identity and a mo= dified SDP). > > Brian > > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > > Would it be possible to provide an indication of whether the calling > name was validated (in the same sense that the calling number was > validated, but an independent indication)?____ > > __ __ > > ISTM that should be a simple exercise, protocol-wise. And it > maintains the parallel treatment of name and number that we have > today (e.g., there are today separate indications of privacy, for > name and number). But that's not my main concern; mostly I'm > thinking of the evolution of the process by which calling name is > provided. Even if it's not possible to validate calling name as > provided by CNAM, it might be possible to validate calling name as > provided by other methods; e.g., by the calling network in the > display-name header field in the FROM or (more likely in public > networks) the P-A-ID header.____ > > __ __ > > tim____ > > __ __ > > __ __ > > *From:*stir-bounces@ietf.org 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org > ] *On Behalf Of > *PFAUTZ, PENN L > *Sent:* Wednesday, August 14, 2013 9:37 AM > *To:* Brian Rosen; Hadriel Kaplan > *Cc:* stir@ietf.org ; > Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I assume the concern in this thread is with the case where a number > might be authenticated but the CNAM displayed would be misleading > because of lax policies of the CNAM provider - e.g., the bad guy > makes a call from what is indeed his legit number but has managed to > get Bank of America into his CNAM entry.____ > > __ __ > > I'm thinking that taking on CNAM in the ietf may be a bridge too far > for stir. Leave what happens after the number is validated up to > national authorities since arrangements may differ. And at least in > the case above it should be possible to trace back to the=20 > perp.____ > > __ __ > > More generally I think the object of stir ought to be just to > provide the customer an indication of whether the calling number was > validated on not - whether calls get blocked or unvalidated numbers > are still displayed should be up to the customer and their service > provider.____ > > __ __ > > Penn Pfautz____ > > AT&T Access Management____ > > +1-732-420-4962____ > > *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On > Behalf Of *Brian Rosen > *Sent:* Wednesday, August 14, 2013 9:32 AM > *To:* Hadriel Kaplan > *Cc:* stir@ietf.org; Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I think we probably should keep CNAM out of this for now=20 > anyway.____ > > __ __ > > The advantage of the credential delegation process as we have > defined it is that it's authoritative.____ > > __ __ > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on > on behalf of the origination carrier and queried by the termination > carrier (often with a charge to query). The content is what the > carrier has recorde from the original service order, but there isn't > any attempt to validate those names, and there are carriers who will > let you put anything you like in there. How "authoritative" is > that? Then there are other databases, like Neustar's, that don't > have any relationship to the originination carrier - the termination > carrier dips an independently developed database of name-number > relationships. These databases are developed using a wide variety > of sources and have evolved to be very accurate, but hardly > "authoritative".____ > > __ __ > > And yes, Hadriel, there are regulatory restrictions, mostly about > what the NPAC (number portability database administrator) can do. > The CNAM databases have very few regulations to deal with.____ > > __ __ > > Brian ____ > > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Wed Aug 14 12:57:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADF711E80FF for ; Wed, 14 Aug 2013 12:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAYw+6DW375k for ; Wed, 14 Aug 2013 12:57:30 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D221F9034 for ; Wed, 14 Aug 2013 12:57:30 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id CiE41m0060ldTLk53jxVvo; Wed, 14 Aug 2013 19:57:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id CjxV1m00g3ZTu2S01jxVQU; Wed, 14 Aug 2013 19:57:29 +0000 Message-ID: <520BE128.8090704@alum.mit.edu> Date: Wed, 14 Aug 2013 21:57:28 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <287AA00B-357C-4625-9C38-0C8A3AC6D715@oracle.com> In-Reply-To: <287AA00B-357C-4625-9C38-0C8A3AC6D715@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376510249; bh=U1APGxj6VWvxSoMrmi1TDne7QjS5bd3T0RE8pQ1+yIE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EMemP+b92Q/hR5KObVwvQ8Xgjxh3cTzThECMwVveWq1Dvgb6wKmt4YWVzpP79EGZ/ PUOEt57xt6EbuJeh06THEJiCft6GZ4OK9JYWWWES2bf6QJFvm0Ah0V1IoshvNC8eoy dedQu+p8BkipYyE6G+9St8A+yWzcV99Nomav4fV+sy8gL5FHktuSMG5VJhhErG65ng zCQnb9ApV5wkm67X2uKIL8QeWp9WShm8fF/NxWXXvUajGX4PhVax9FQ8DJWFmH9dPT +8qLUcufy6Q1RUFwT1Yw0IdPeKUB2XAsZm9/WtRaof04nJnAY9uArmTlUsOcdAOtLh bK89zjXUaL0sQ== Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 19:57:35 -0000 On 8/14/13 9:13 PM, Hadriel Kaplan wrote: > > I don't think we can solve that problem. A different problem, which may be what Tim was getting at, is how a SIP endpoint receiving a message knows whether its local SIP Service Provider believes the calling-name is accurate or not. > > In other words, suppose your SSP did use a CNAM database that was reasonably accurate, and even used a STIR-validated number to get the info from the CNAM DB. When you receive an INVITE, which message header field do you use for calling-name display, and how do you know it was populated by your SSP based on STIR-validated information? > > Today, the answer is basically that you trust your SSP to get it right; and the field a lot of folks use is the display-name portion of the From, or the display-name portion of the PAI if it's there. > > The same can be said for the source identity calling number, in terms of what today's behavior is. And even when this STIR thing gets deployed, there's no indication in SIP that your SSP actually performed STIR validation. The assumption is it did perform it, and if the validation failed it would change the From to be 'sip:unknown@unknown.invalid' or 'sip:invalid@invalid' or whatever.[1] ISTM that the feature you are describing can be satisfied by P-A-ID, in contexts where that can be trusted. In contexts where it *can't* be trusted, then we have no solution for caller name. Thanks, Paul > -hadriel > [1] I'm not saying we shouldn't be more explicit in this behavior in our docs once we get a WG, but right now it's undefined. > > On Aug 14, 2013, at 2:38 PM, Brian Rosen wrote: > >> I suppose it's possible, but what is the criteria for validation? >> >> With TNs, we have credentials that accompany number delegation - we have a clear path to assuring that the caller asserting the identity is indeed entitled to claim control of that number (well, SPs mostly, not the caller, at least initially). There is no equivalent assurance for CNAM. >> >> I don't want to get into a fight over which database is better, but the alternate, doesn't depend on the origination carrier mechansism is statisically actually a better "validation" of the content than what a traditional carrier gets in his service order (because they usually don't actually validate the content), and is infiniately better than the carriers that allow the consumer to put anything they want in the database. Without a reasonable way to assure that the database is actually valid, what is the value of carrying an assertion? >> >> If we had such a mechanism, what prevents one of the carriers that let's you put anything you want in the database from asserting that the content of P-A-ID is valid, when the user is allowed to say whatever they want goes in P-A-ID? >> >> The best thing I can come up with would be to have some independent validation service that used other data sources to validate the content, and let them sign it. Then we could carry that signature somewhere. >> >> Right now, I think we should leave it out of scope. If we can figure out a way to do validation, then we can revisit the notion of carrying evidence of validation in future work. >> >> Does argue for making sure that whatever mechanism we arrive at should have some obvious extension mechanism, perhaps along the lines of what Jon was suggesting for media properties. If you recall, he proposed to have a digest of SDP where the digest was protected by the signature, but if the SDP received didn't match the SDP sent, the termination side could know that, but the basic identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP). >> >> Brian >> >> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >> Would it be possible to provide an indication of whether the calling name was validated (in the same sense that the calling number was validated, but an independent indication)? >> >> >> >> ISTM that should be a simple exercise, protocol-wise. And it maintains the parallel treatment of name and number that we have today (e.g., there are today separate indications of privacy, for name and number). But that’s not my main concern; mostly I’m thinking of the evolution of the process by which calling name is provided. Even if it’s not possible to validate calling name as provided by CNAM, it might be possible to validate calling name as provided by other methods; e.g., by the calling network in the display-name header field in the FROM or (more likely in public networks) the P-A-ID header. >> >> >> >> tim >> >> >> >> >> >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L >> Sent: Wednesday, August 14, 2013 9:37 AM >> To: Brian Rosen; Hadriel Kaplan >> Cc: stir@ietf.org; Paul Kyzivat >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) >> >> >> >> I assume the concern in this thread is with the case where a number might be authenticated but the CNAM displayed would be misleading because of lax policies of the CNAM provider – e.g., the bad guy makes a call from what is indeed his legit number but has managed to get Bank of America into his CNAM entry. >> >> >> >> I’m thinking that taking on CNAM in the ietf may be a bridge too far for stir. Leave what happens after the number is validated up to national authorities since arrangements may differ. And at least in the case above it should be possible to trace back to the perp. >> >> >> >> More generally I think the object of stir ought to be just to provide the customer an indication of whether the calling number was validated on not – whether calls get blocked or unvalidated numbers are still displayed should be up to the customer and their service provider. >> >> >> >> Penn Pfautz >> >> AT&T Access Management >> >> +1-732-420-4962 >> >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >> Sent: Wednesday, August 14, 2013 9:32 AM >> To: Hadriel Kaplan >> Cc: stir@ietf.org; Paul Kyzivat >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) >> >> >> >> I think we probably should keep CNAM out of this for now anyway. >> >> >> >> The advantage of the credential delegation process as we have defined it is that it's authoritative. >> >> >> >> The current CNAM databases cannot be called "authoritative" really. Classically, as you describe, there is a database operated by on on behalf of the origination carrier and queried by the termination carrier (often with a charge to query). The content is what the carrier has recorde from the original service order, but there isn't any attempt to validate those names, and there are carriers who will let you put anything you like in there. How "authoritative" is that? Then there are other databases, like Neustar's, that don't have any relationship to the originination carrier - the termination carrier dips an independently developed database of name-number relationships. These databases are developed using a wide variety of sources and have evolved to be very accurate, but hardly "authoritative". >> >> >> >> And yes, Hadriel, there are regulatory restrictions, mostly about what the NPAC (number portability database administrator) can do. The CNAM databases have very few regulations to deal with. >> >> >> >> Brian >> >> >> On Wednesday, August 14, 2013, Hadriel Kaplan wrote: >> >> >> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat > >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From richard@shockey.us Wed Aug 14 14:26:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BBC21E80DB for ; Wed, 14 Aug 2013 14:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.536 X-Spam-Level: X-Spam-Status: No, score=-100.536 tagged_above=-999 required=5 tests=[AWL=-1.529, BAYES_00=-2.599, FRT_PENIS1=3.592, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIUeH0A849oU for ; Wed, 14 Aug 2013 14:26:46 -0700 (PDT) Received: from oproxy12-pub.mail.unifiedlayer.com (oproxy12-pub.mail.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 9049421E80DD for ; Wed, 14 Aug 2013 14:26:46 -0700 (PDT) Received: (qmail 9119 invoked by uid 0); 14 Aug 2013 21:26:14 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.mail.unifiedlayer.com with SMTP; 14 Aug 2013 21:26:14 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=va1IoaAgxvjk09deXfufssXDM3+LjKT02fEnn+Mco2A=; b=LbpO2EDmBrATKV8asusxSOb/mNZIkarTEzl4L6hW90QbBH52GyoqpDc7ifGxDLmbJE2zKu0Cl6BZnp/EYkavyKA/jI/lGKTsy/PXG/2YT4jr2gRUP4snGGF3flujYLU6; Received: from [71.114.100.16] (port=52607 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V9ia5-00085Z-RW; Wed, 14 Aug 2013 15:26:14 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , "'Paul Kyzivat'" , "'Brian Rosen'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> In-Reply-To: Date: Wed, 14 Aug 2013 17:26:10 -0400 Message-ID: <005f01ce9934$e65607f0$b30217d0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zAmNFLYoCnpukhgIjunD9AcypclECnwcp9wH9UiaQAehfhtMCbBHbEgHDEuIkAgFiOZEBpfjYOgI3GZrTAw9GpewBvldmIQGLSzD+AbpzlT2XoyLxMA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 21:26:51 -0000 Oh well its August... time for leisurely conversation. My concern is how the UA can display the validation data for Caller ID or what the SSP maybe/might/theoretically thinks about it. There is a rich vein of inquiry here but STIR is not the place to do it. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Wednesday, August 14, 2013 3:19 PM To: 'Paul Kyzivat'; Brian Rosen Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Just piling on... There are at least three levels of information here, making it difficult to do that within the signaling framework: * the name of the person calling (vs. the subscriber name) * the name of the organization * properties of the organization ("licensed plumber", "FDIC-insured bank", "located in Washington, DC", "registered charity") This is more whois-like information than just the SIP display name. In the certificate space, we have two levels: (1) assertion of domain name control; (2) EV (extended validation) certs. It would be interesting to see how well the EV concept has worked out in practice. I don't see how signing helps here at all, for the reasons mentioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimate number with just about any name string. And for corporate accounts, the service provider has no way of knowing whether Tom Sawyer is really at a particular number in a range and whether that entity prefers to list the name of the person, just the organization, the location ("PizzaHut Leonia") or something else. Indeed, the same number can legitimately have multiple display names that change quickly over time (e.g., staff at the doctor's office). Verifiable whois-like information could be very useful and service providers could see that as an opportunity, given that they do know a lot about their customers, such as their billing and service address and how long they have been in business. But it's a separate problem, probably more closely related to the number allocation problem. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, August 14, 2013 3:04 PM To: Brian Rosen Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On 8/14/13 8:38 PM, Brian Rosen wrote: > I suppose it's possible, but what is the criteria for validation? > > With TNs, we have credentials that accompany number delegation - we > have a clear path to assuring that the caller asserting the identity > is indeed entitled to claim control of that number (well, SPs mostly, > not the caller, at least initially). There is no equivalent assurance > for CNAM. > > I don't want to get into a fight over which database is better, but > the alternate, doesn't depend on the origination carrier mechansism is > statisically actually a better "validation" of the content than what a > traditional carrier gets in his service order (because they usually > don't actually validate the content), and is infiniately better than > the carriers that allow the consumer to put anything they want in the > database. Without a reasonable way to assure that the database is > actually valid, what is the value of carrying an assertion? While I recognize that letting the customer put in whatever they want is problematic, I have no idea whether the alternative of letting the CNAM provider include whatever they want is "better". (How would we measure that?) (I've just been trying to deal with an "information aggregator" that is publishing wrong information about me and won't change it. So I'm not feeling good about that sort of thing.) ISTM that is is yet another example of ancient, informal, manual systems, that once mostly "worked" based on the good will of the people involved, but that have now been automated into monstrosities that nobody understands. (Management of healthcare data is another example.) Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws. Alternatively this could be left to the open market. (E.g., The callee could just Google the calling number.) In any case STIR can't go down this rat hole. Thanks, Paul > If we had such a mechanism, what prevents one of the carriers that > let's you put anything you want in the database from asserting that > the content of P-A-ID is valid, when the user is allowed to say > whatever they want goes in P-A-ID? > > The best thing I can come up with would be to have some independent > validation service that used other data sources to validate the > content, and let them sign it. Then we could carry that signature somewhere. > > Right now, I think we should leave it out of scope. If we can figure > out a way to do validation, then we can revisit the notion of carrying > evidence of validation in future work. > > Does argue for making sure that whatever mechanism we arrive at should > have some obvious extension mechanism, perhaps along the lines of what > Jon was suggesting for media properties. If you recall, he proposed > to have a digest of SDP where the digest was protected by the > signature, but if the SDP received didn't match the SDP sent, the > termination side could know that, but the basic identity mechanism > could succeed anyway (that is, you knew you had a valid identity and a modified SDP). > > Brian > > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > > Would it be possible to provide an indication of whether the calling > name was validated (in the same sense that the calling number was > validated, but an independent indication)?____ > > __ __ > > ISTM that should be a simple exercise, protocol-wise. And it > maintains the parallel treatment of name and number that we have > today (e.g., there are today separate indications of privacy, for > name and number). But that's not my main concern; mostly I'm > thinking of the evolution of the process by which calling name is > provided. Even if it's not possible to validate calling name as > provided by CNAM, it might be possible to validate calling name as > provided by other methods; e.g., by the calling network in the > display-name header field in the FROM or (more likely in public > networks) the P-A-ID header.____ > > __ __ > > tim____ > > __ __ > > __ __ > > *From:*stir-bounces@ietf.org 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org > ] *On Behalf Of > *PFAUTZ, PENN L > *Sent:* Wednesday, August 14, 2013 9:37 AM > *To:* Brian Rosen; Hadriel Kaplan > *Cc:* stir@ietf.org ; > Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I assume the concern in this thread is with the case where a number > might be authenticated but the CNAM displayed would be misleading > because of lax policies of the CNAM provider - e.g., the bad guy > makes a call from what is indeed his legit number but has managed to > get Bank of America into his CNAM entry.____ > > __ __ > > I'm thinking that taking on CNAM in the ietf may be a bridge too far > for stir. Leave what happens after the number is validated up to > national authorities since arrangements may differ. And at least in > the case above it should be possible to trace back to the > perp.____ > > __ __ > > More generally I think the object of stir ought to be just to > provide the customer an indication of whether the calling number was > validated on not - whether calls get blocked or unvalidated numbers > are still displayed should be up to the customer and their service > provider.____ > > __ __ > > Penn Pfautz____ > > AT&T Access Management____ > > +1-732-420-4962____ > > *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On > Behalf Of *Brian Rosen > *Sent:* Wednesday, August 14, 2013 9:32 AM > *To:* Hadriel Kaplan > *Cc:* stir@ietf.org; Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I think we probably should keep CNAM out of this for now > anyway.____ > > __ __ > > The advantage of the credential delegation process as we have > defined it is that it's authoritative.____ > > __ __ > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on > on behalf of the origination carrier and queried by the termination > carrier (often with a charge to query). The content is what the > carrier has recorde from the original service order, but there isn't > any attempt to validate those names, and there are carriers who will > let you put anything you like in there. How "authoritative" is > that? Then there are other databases, like Neustar's, that don't > have any relationship to the originination carrier - the termination > carrier dips an independently developed database of name-number > relationships. These databases are developed using a wide variety > of sources and have evolved to be very accurate, but hardly > "authoritative".____ > > __ __ > > And yes, Hadriel, there are regulatory restrictions, mostly about > what the NPAC (number portability database administrator) can do. > The CNAM databases have very few regulations to deal with.____ > > __ __ > > Brian ____ > > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Wed Aug 14 15:14:44 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EB821F9B26 for ; Wed, 14 Aug 2013 15:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.258 X-Spam-Level: X-Spam-Status: No, score=-0.258 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Asu1O5uCF-Xk for ; Wed, 14 Aug 2013 15:14:40 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id BC8E121F9BAB for ; Wed, 14 Aug 2013 15:14:39 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta07.westchester.pa.mail.comcast.net with comcast id CbUU1m0031YDfWL57mEfsi; Wed, 14 Aug 2013 22:14:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id CmEd1m00r3ZTu2S3gmEdz5; Wed, 14 Aug 2013 22:14:39 +0000 Message-ID: <520C014D.4010909@alum.mit.edu> Date: Thu, 15 Aug 2013 00:14:37 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Richard Shockey References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <005f01ce9934$e65607f0$b30217d0$@shockey.us> In-Reply-To: <005f01ce9934$e65607f0$b30217d0$@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376518479; bh=yyWow1MCOV/uOQJ59Jc5IZy/jBmqXK/C1qk2U27DYco=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sI6eRZSeEMj1a4q/OIlCg+zTTXDpfwWJNhhqfWDp6tevPNEi7sHBFrgBCZQReB3M6 b+6nik0/SG1TqBw3kJ6G8ubuKR2IVM5P2QBZDZBeur5FjSvwb8c7dIYeCiNwEolGvU eXd4n7PITwGdXm1PNIRqyqcQw78UduTExpPNC5j+9S/PS3Wkzn71o7fMo1flKdpR1/ Fdtv65uc42obRhnFQD+ksSP0gY78T5eAwSVBTI4gOUkObINhjn4SsH3O5shMczLWKB s7JZUIlnRQy1MNA8kw2OleNgWHB+UFAuxe4RIuSTp7GCi5yuoUidz21VMNHuREFPo0 TLZQolUhP5U1g== Cc: stir@ietf.org, 'Brian Rosen' , 'Henning Schulzrinne' Subject: [stir] Digression on CNAM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 22:14:44 -0000 On 8/14/13 11:26 PM, Richard Shockey wrote: > Oh well its August... time for leisurely conversation. > > My concern is how the UA can display the validation data for Caller ID or > what the SSP maybe/might/theoretically thinks about it. There is a rich > vein of inquiry here but STIR is not the place to do it. The limitations of callerid display on traditional phone devices really constrains what can be done. But we are gradually evolving away from those constraints. It might really be better to leave this to the device to deal with. Less constrained devices could easily: - just use the info from the local address book, if there is any - do a fairly general google-like query for info about the number and some heuristic pruning to choose what to display - pop it all up in a window. Thanks, Paul > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Wednesday, August 14, 2013 3:19 PM > To: 'Paul Kyzivat'; Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > Just piling on... There are at least three levels of information here, > making it difficult to do that within the signaling framework: > > * the name of the person calling (vs. the subscriber name) > * the name of the organization > * properties of the organization ("licensed plumber", "FDIC-insured bank", > "located in Washington, DC", "registered charity") > > This is more whois-like information than just the SIP display name. In the > certificate space, we have two levels: (1) assertion of domain name control; > (2) EV (extended validation) certs. It would be interesting to see how well > the EV concept has worked out in practice. > > I don't see how signing helps here at all, for the reasons mentioned. > Nefarious actors can use services such as http://www.callerid4u.com/ to use > a legitimate number with just about any name string. And for corporate > accounts, the service provider has no way of knowing whether Tom Sawyer is > really at a particular number in a range and whether that entity prefers to > list the name of the person, just the organization, the location ("PizzaHut > Leonia") or something else. Indeed, the same number can legitimately have > multiple display names that change quickly over time (e.g., staff at the > doctor's office). > > Verifiable whois-like information could be very useful and service providers > could see that as an opportunity, given that they do know a lot about their > customers, such as their billing and service address and how long they have > been in business. But it's a separate problem, probably more closely related > to the number allocation problem. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: Wednesday, August 14, 2013 3:04 PM > To: Brian Rosen > Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > On 8/14/13 8:38 PM, Brian Rosen wrote: >> I suppose it's possible, but what is the criteria for validation? >> >> With TNs, we have credentials that accompany number delegation - we >> have a clear path to assuring that the caller asserting the identity >> is indeed entitled to claim control of that number (well, SPs mostly, >> not the caller, at least initially). There is no equivalent assurance >> for CNAM. >> >> I don't want to get into a fight over which database is better, but >> the alternate, doesn't depend on the origination carrier mechansism is >> statisically actually a better "validation" of the content than what a >> traditional carrier gets in his service order (because they usually >> don't actually validate the content), and is infiniately better than >> the carriers that allow the consumer to put anything they want in the >> database. Without a reasonable way to assure that the database is >> actually valid, what is the value of carrying an assertion? > > While I recognize that letting the customer put in whatever they want is > problematic, I have no idea whether the alternative of letting the CNAM > provider include whatever they want is "better". (How would we measure > that?) > > (I've just been trying to deal with an "information aggregator" that is > publishing wrong information about me and won't change it. So I'm not > feeling good about that sort of thing.) > > ISTM that is is yet another example of ancient, informal, manual systems, > that once mostly "worked" based on the good will of the people involved, but > that have now been automated into monstrosities that nobody understands. > (Management of healthcare data is another example.) > > Ultimately there will need to be a big effort to develop a formal framework > for this. And it will probably require the creation of new laws. > > Alternatively this could be left to the open market. (E.g., The callee could > just Google the calling number.) > > In any case STIR can't go down this rat hole. > > Thanks, > Paul > >> If we had such a mechanism, what prevents one of the carriers that >> let's you put anything you want in the database from asserting that >> the content of P-A-ID is valid, when the user is allowed to say >> whatever they want goes in P-A-ID? >> >> The best thing I can come up with would be to have some independent >> validation service that used other data sources to validate the >> content, and let them sign it. Then we could carry that signature > somewhere. >> >> Right now, I think we should leave it out of scope. If we can figure >> out a way to do validation, then we can revisit the notion of carrying >> evidence of validation in future work. >> >> Does argue for making sure that whatever mechanism we arrive at should >> have some obvious extension mechanism, perhaps along the lines of what >> Jon was suggesting for media properties. If you recall, he proposed >> to have a digest of SDP where the digest was protected by the >> signature, but if the SDP received didn't match the SDP sent, the >> termination side could know that, but the basic identity mechanism >> could succeed anyway (that is, you knew you had a valid identity and a > modified SDP). >> >> Brian >> >> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >> >> Would it be possible to provide an indication of whether the calling >> name was validated (in the same sense that the calling number was >> validated, but an independent indication)?____ >> >> __ __ >> >> ISTM that should be a simple exercise, protocol-wise. And it >> maintains the parallel treatment of name and number that we have >> today (e.g., there are today separate indications of privacy, for >> name and number). But that's not my main concern; mostly I'm >> thinking of the evolution of the process by which calling name is >> provided. Even if it's not possible to validate calling name as >> provided by CNAM, it might be possible to validate calling name as >> provided by other methods; e.g., by the calling network in the >> display-name header field in the FROM or (more likely in public >> networks) the P-A-ID header.____ >> >> __ __ >> >> tim____ >> >> __ __ >> >> __ __ >> >> *From:*stir-bounces@ietf.org > 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >> ] *On Behalf Of >> *PFAUTZ, PENN L >> *Sent:* Wednesday, August 14, 2013 9:37 AM >> *To:* Brian Rosen; Hadriel Kaplan >> *Cc:* stir@ietf.org ; >> Paul Kyzivat >> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter)____ >> >> __ __ >> >> I assume the concern in this thread is with the case where a number >> might be authenticated but the CNAM displayed would be misleading >> because of lax policies of the CNAM provider - e.g., the bad guy >> makes a call from what is indeed his legit number but has managed to >> get Bank of America into his CNAM entry.____ >> >> __ __ >> >> I'm thinking that taking on CNAM in the ietf may be a bridge too far >> for stir. Leave what happens after the number is validated up to >> national authorities since arrangements may differ. And at least in >> the case above it should be possible to trace back to the >> perp.____ >> >> __ __ >> >> More generally I think the object of stir ought to be just to >> provide the customer an indication of whether the calling number was >> validated on not - whether calls get blocked or unvalidated numbers >> are still displayed should be up to the customer and their service >> provider.____ >> >> __ __ >> >> Penn Pfautz____ >> >> AT&T Access Management____ >> >> +1-732-420-4962____ >> >> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >> Behalf Of *Brian Rosen >> *Sent:* Wednesday, August 14, 2013 9:32 AM >> *To:* Hadriel Kaplan >> *Cc:* stir@ietf.org; Paul Kyzivat >> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter)____ >> >> __ __ >> >> I think we probably should keep CNAM out of this for now >> anyway.____ >> >> __ __ >> >> The advantage of the credential delegation process as we have >> defined it is that it's authoritative.____ >> >> __ __ >> >> The current CNAM databases cannot be called "authoritative" really. >> Classically, as you describe, there is a database operated by on >> on behalf of the origination carrier and queried by the termination >> carrier (often with a charge to query). The content is what the >> carrier has recorde from the original service order, but there isn't >> any attempt to validate those names, and there are carriers who will >> let you put anything you like in there. How "authoritative" is >> that? Then there are other databases, like Neustar's, that don't >> have any relationship to the originination carrier - the termination >> carrier dips an independently developed database of name-number >> relationships. These databases are developed using a wide variety >> of sources and have evolved to be very accurate, but hardly >> "authoritative".____ >> >> __ __ >> >> And yes, Hadriel, there are regulatory restrictions, mostly about >> what the NPAC (number portability database administrator) can do. >> The CNAM databases have very few regulations to deal with.____ >> >> __ __ >> >> Brian ____ >> >> >> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >> >> >> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > From timothy.dwight@verizon.com Thu Aug 15 12:15:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AEC21F9D5F for ; Thu, 15 Aug 2013 12:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.294 X-Spam-Level: X-Spam-Status: No, score=0.294 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgKDYXsLfggv for ; Thu, 15 Aug 2013 12:15:51 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id 0E07221F9D5D for ; Thu, 15 Aug 2013 12:15:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe01.verizonbusiness.com with ESMTP; 15 Aug 2013 19:15:48 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,887,1367971200"; d="scan'208,217";a="527529281" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi02.verizon.com with ESMTP; 15 Aug 2013 19:15:48 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Thu, 15 Aug 2013 15:15:43 -0400 To: Brian Rosen Date: Thu, 15 Aug 2013 15:15:42 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: Ac6ZHXGKIL2OCAhsTKmYxRG1H0c+nQAy3YyQ Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3A08@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@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: multipart/alternative; boundary="_000_2B0F677F0B95454297753F58D4A07FA3012ADB3A08FHDP1LUMXC7V3_" MIME-Version: 1.0 Cc: "stir@ietf.org" , Hadriel Kaplan , "PFAUTZ, PENN L" , Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:15:57 -0000 --_000_2B0F677F0B95454297753F58D4A07FA3012ADB3A08FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure what the objection to validating calling name, is. Is it... a) It's too hard b) It's not necessary c) It isn't easily achieved using the solution we've already selected The first strikes me as odd since it's been suggested that the smartphone c= ould do it itself. Surely whatever an app on a smartphone can do, we can d= o. The second seems to leave a significant community of users still at risk. = Scammers can continue to target consumers, e.g., using numbers they've obta= ined from the victim's area code and with which they've been allowed by som= e shady entity to associate the name of the victim's bank. Maybe that woul= dn't fool a law enforcement agency or a PSAP (because they have their own i= dentity databases), but it'd fool my mother. I doubt she's memorized the p= hone number of her bank, and if she sees the name of her bank in the caller= ID display (and if the nice man seems convincing) I suspect she'll believe= she's talking to the bank. Is this scenario not in scope? Or is the real objection, that we don't want to consider requirements that = don't fit (or might complicate) the solution we've already locked in on? Tim From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, August 14, 2013 1:38 PM To: Dwight, Timothy M (Tim) Cc: PFAUTZ, PENN L; Hadriel Kaplan; stir@ietf.org; Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I suppose it's possible, but what is the criteria for validation? With TNs, we have credentials that accompany number delegation - we have a = clear path to assuring that the caller asserting the identity is indeed ent= itled to claim control of that number (well, SPs mostly, not the caller, at= least initially). There is no equivalent assurance for CNAM. I don't want to get into a fight over which database is better, but the alt= ernate, doesn't depend on the origination carrier mechansism is statisicall= y actually a better "validation" of the content than what a traditional car= rier gets in his service order (because they usually don't actually validat= e the content), and is infiniately better than the carriers that allow the = consumer to put anything they want in the database. Without a reasonable w= ay to assure that the database is actually valid, what is the value of carr= ying an assertion? If we had such a mechanism, what prevents one of the carriers that let's yo= u put anything you want in the database from asserting that the content of = P-A-ID is valid, when the user is allowed to say whatever they want goes in= P-A-ID? The best thing I can come up with would be to have some independent validat= ion service that used other data sources to validate the content, and let t= hem sign it. Then we could carry that signature somewhere. Right now, I think we should leave it out of scope. If we can figure out a= way to do validation, then we can revisit the notion of carrying evidence = of validation in future work. Does argue for making sure that whatever mechanism we arrive at should have= some obvious extension mechanism, perhaps along the lines of what Jon was = suggesting for media properties. If you recall, he proposed to have a dige= st of SDP where the digest was protected by the signature, but if the SDP r= eceived didn't match the SDP sent, the termination side could know that, bu= t the basic identity mechanism could succeed anyway (that is, you knew you = had a valid identity and a modified SDP). Brian On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: Would it be possible to provide an indication of whether the calling name w= as validated (in the same sense that the calling number was validated, but = an independent indication)? ISTM that should be a simple exercise, protocol-wise. And it maintains the= parallel treatment of name and number that we have today (e.g., there are = today separate indications of privacy, for name and number). But that's no= t my main concern; mostly I'm thinking of the evolution of the process by w= hich calling name is provided. Even if it's not possible to validate calli= ng name as provided by CNAM, it might be possible to validate calling name = as provided by other methods; e.g., by the calling network in the display-n= ame header field in the FROM or (more likely in public networks) the P-A-ID= header. tim From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Wednesday, August 14, 2013 9:37 AM To: Brian Rosen; Hadriel Kaplan Cc: stir@ietf.org; Pau= l Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I assume the concern in this thread is with the case where a number might b= e authenticated but the CNAM displayed would be misleading because of lax p= olicies of the CNAM provider - e.g., the bad guy makes a call from what is = indeed his legit number but has managed to get Bank of America into his CNA= M entry. I'm thinking that taking on CNAM in the ietf may be a bridge too far for st= ir. Leave what happens after the number is validated up to national authori= ties since arrangements may differ. And at least in the case above it shoul= d be possible to trace back to the perp. More generally I think the object of stir ought to be just to provide the c= ustomer an indication of whether the calling number was validated on not - = whether calls get blocked or unvalidated numbers are still displayed should= be up to the customer and their service provider. Penn Pfautz AT&T Access Management +1-732-420-4962 From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, August 14, 2013 9:32 AM To: Hadriel Kaplan Cc: stir@ietf.org; Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I think we probably should keep CNAM out of this for now anyway. The advantage of the credential delegation process as we have defined it is= that it's authoritative. The current CNAM databases cannot be called "authoritative" really. Classi= cally, as you describe, there is a database operated by on on behalf of the= origination carrier and queried by the termination carrier (often with a c= harge to query). The content is what the carrier has recorde from the orig= inal service order, but there isn't any attempt to validate those names, an= d there are carriers who will let you put anything you like in there. How = "authoritative" is that? Then there are other databases, like Neustar's, t= hat don't have any relationship to the originination carrier - the terminat= ion carrier dips an independently developed database of name-number relatio= nships. These databases are developed using a wide variety of sources and = have evolved to be very accurate, but hardly "authoritative". And yes, Hadriel, there are regulatory restrictions, mostly about what the = NPAC (number portability database administrator) can do. The CNAM databases= have very few regulations to deal with. Brian On Wednesday, August 14, 2013, Hadriel Kaplan wrote: On Aug 13, 2013, at 10:20 PM, Paul Kyzivat

I’m not sure what th= e objection to validating calling name, is.  Is it…

 

= a) =      It’s too hard

b)      It’s not necessary

<= span style=3D'mso-list:Ignore'>c)It isn’t easil= y achieved using the solution we’ve already selected

 

The first strikes me= as odd since it’s been suggested that the smartphone could do it its= elf.  Surely whatever an app on a smartphone can do, we can do.

 

= The second= seems to leave a significant community of users still at risk.  Scamm= ers can continue to target consumers, e.g., using numbers they’ve obt= ained from the victim’s area code and with which they’ve been a= llowed by some shady entity to associate the name of the victim’s ban= k.  Maybe that wouldn’t fool a law enforcement agency or a PSAP = (because they have their own identity databases), but it’d fool my mo= ther.  I doubt she’s memorized the phone number of her bank, and= if she sees the name of her bank in the caller ID display (and if the nice= man seems convincing) I suspect she’ll believe she’s talking t= o the bank.  Is this scenario not in scope?

 

Or is the real objection, tha= t we don’t want to consider requirements that don’t fit (or mig= ht complicate) the solution we’ve already locked in on?

 

Tim

 

 =

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = Brian Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, August 1= 4, 2013 1:38 PM
To: Dwight, Timothy M (Tim)
Cc: PFAUTZ,= PENN L; Hadriel Kaplan; stir@ietf.org; Paul Kyzivat
Subject: Re:= [stir] Early Homework (was Re: Moving from BOF to Charter)

 

I supp= ose it's possible, but what is the criteria for validation?

<= div>

 

With TNs, we have credentials that accompany number delegation - we have= a clear path to assuring that the caller asserting the identity is indeed = entitled to claim control of that number (well, SPs mostly, not the caller,= at least initially).  There is no equivalent assurance for CNAM. &nbs= p;

 

I don't want to get into a fight over which data= base is better, but the alternate, doesn't depend on the origination carrie= r mechansism is statisically actually a better "validation" = of the content than what a traditional carrier gets in his service order (b= ecause they usually don't actually validate the content), and is infiniatel= y better than the carriers that allow the consumer to put anything they wan= t in the database.  Without a reasonable way to assure that the databa= se is actually valid, what is the value of carrying an assertion?

 

If we had such a mechanism, what prevents one of the carrier= s that let's you put anything you want in the database from asserting that = the content of P-A-ID is valid, when the user is allowed to say whatever th= ey want goes in P-A-ID?

=  

The best thing I can come u= p with would be to have some independent validation service that used other= data sources to validate the content, and let them sign it.  Then we = could carry that signature somewhere. 

 

Right n= ow, I think we should leave it out of scope.  If we can figure out a w= ay to do validation, then we can revisit the notion of carrying evidence of= validation in future work.

<= o:p> 

Does argue for making s= ure that whatever mechanism we arrive at should have some obvious extension= mechanism, perhaps along the lines of what Jon was suggesting for media pr= operties.  If you recall, he proposed to have a digest of SDP where th= e digest was protected by the signature, but if the SDP received didn't mat= ch the SDP sent, the termination side could know that, but the basic identi= ty mechanism could succeed anyway (that is, you knew you had a valid i= dentity and a modified SDP).

=  

Brian

 

On Wednes= day, August 14, 2013, Dwight, Timothy M (Tim) wrote:

W= ould it be possible to provide an indication of whether the calling name wa= s validated (in the same sense that the calling number was validated, but a= n independent indication)?

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>ISTM= that should be a simple exercise, protocol-wise.  And it maintains th= e parallel treatment of name and number that we have today (e.g., there are= today separate indications of privacy, for name and number).  But tha= t’s not my main concern; mostly I’m thinking of the evolution o= f the process by which calling name is provided.  Even if it’s n= ot possible to validate calling name as provided by CNAM, it might be possi= ble to validate calling name as provided by other methods; e.g., by the cal= ling network in the display-name header field in the FROM or (more likely i= n public networks) the P-A-ID header.

 <= /o:p>

tim

 

 

From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] On Behalf Of PFAUTZ,= PENN L
Sent: Wednesday, August 14, 2013 9:37 AM
To: Br= ian Rosen; Hadriel Kaplan
Cc: stir@ietf.org; Paul Kyzi= vat
Subject: Re: [stir] Early Homework (was Re: Moving from BOF t= o Charter)

 

I assume the concern in this thread is with the case where a number migh= t be authenticated but the CNAM displayed would be misleading because of la= x policies of the CNAM provider – e.g., the bad guy makes a call from= what is indeed his legit number but has managed to get Bank of America int= o his CNAM entry.

 

I’m thinking that taking on CNAM in the ietf may be a bri= dge too far for stir. Leave what happens after the number is validated up t= o national authorities since arrangements may differ. And at least in the c= ase above it should be possible to trace back to the perp.

 

More generally I think= the object of stir ought to be just to provide the customer an indication = of whether the calling number was validated on not – whether calls ge= t blocked or unvalidated numbers are still displayed should be up to the cu= stomer and their service provider.

 

Penn Pfautz

AT&= ;T Access Management

+1-732-420-4962

From: stir-bounces@ie= tf.org [mailto:stir-bounces@ie= tf.org] On Behalf Of Brian Rosen
Sent: Wednesday, Augu= st 14, 2013 9:32 AM
To: Hadriel Kaplan
Cc: stir@ietf.org; Paul Kyzivat
Subject: Re:= [stir] Early Homework (was Re: Moving from BOF to Charter)

 

I think we probably should keep CNAM out o= f this for now anyway.

 

The advantage of the credential delegation process as we have defined = it is that it's authoritative.

 

The current CNAM databases cannot be called "author= itative" really.  Classically, as you describe, there is a d= atabase operated by on on behalf of the origination carrier and queried by = the termination carrier (often with a charge to query).  The cont= ent is what the carrier has recorde from the original service order,&n= bsp;but there isn't any attempt to validate those names, and there are carr= iers who will let you put anything you like in there.  How "autho= ritative" is that?  Then there are other databases, like Neustar'= s, that don't have any relationship to the originination carrier - the= termination carrier dips an independently developed database of name-numbe= r relationships.  These databases are developed using a wide variety o= f sources and have evolved to be very accurate, but hardly "authoritat= ive".

 

A= nd yes, Hadriel, there are regulatory restrictions, mostly about what the N= PAC (number portability database administrator) can do. The CNAM databases = have very few regulations to deal with.

 <= o:p>

Brian 

On Wednesday, August 14, 2013, Hadriel Kaplan wrote:

On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <pk

= --_000_2B0F677F0B95454297753F58D4A07FA3012ADB3A08FHDP1LUMXC7V3_-- From timothy.dwight@verizon.com Thu Aug 15 12:25:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C150C11E8156 for ; Thu, 15 Aug 2013 12:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=1.947, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz7xQOhlnGn6 for ; Thu, 15 Aug 2013 12:25:38 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id A489C11E8167 for ; Thu, 15 Aug 2013 12:25:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 15 Aug 2013 19:25:31 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,887,1367971200"; d="scan'208";a="527536563" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 15 Aug 2013 19:25:27 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Thu, 15 Aug 2013 15:25:20 -0400 To: Hadriel Kaplan , Brian Rosen Date: Thu, 15 Aug 2013 15:25:19 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: Ac6ZInwooifX1NupTv2lGUlC/8SvogAyYU7g Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3A1A@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <287AA00B-357C-4625-9C38-0C8A3AC6D715@oracle.com> In-Reply-To: <287AA00B-357C-4625-9C38-0C8A3AC6D715@oracle.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:25:43 -0000 I suppose I would be happy with a cryptographically secure way for the call= ed party to know what entity provided the calling name he sees on his calle= r ID display, and whether that entity asserts its usage to be valid. That = would let the called party make an informed decision about whether to trust= what he sees. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Wednesday, August 14, 2013 2:14 PM To: Brian Rosen Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I don't think we can solve that problem. A different problem, which may be= what Tim was getting at, is how a SIP endpoint receiving a message knows w= hether its local SIP Service Provider believes the calling-name is accurate= or not. In other words, suppose your SSP did use a CNAM database that was reasonabl= y accurate, and even used a STIR-validated number to get the info from the = CNAM DB. When you receive an INVITE, which message header field do you use= for calling-name display, and how do you know it was populated by your SSP= based on STIR-validated information? Today, the answer is basically that you trust your SSP to get it right; and= the field a lot of folks use is the display-name portion of the From, or t= he display-name portion of the PAI if it's there. The same can be said for the source identity calling number, in terms of wh= at today's behavior is. And even when this STIR thing gets deployed, there= 's no indication in SIP that your SSP actually performed STIR validation. = The assumption is it did perform it, and if the validation failed it would = change the From to be 'sip:unknown@unknown.invalid' or 'sip:invalid@invalid= ' or whatever.[1] -hadriel [1] I'm not saying we shouldn't be more explicit in this behavior in our do= cs once we get a WG, but right now it's undefined. On Aug 14, 2013, at 2:38 PM, Brian Rosen wrote: > I suppose it's possible, but what is the criteria for validation? >=20 > With TNs, we have credentials that accompany number delegation - we have = a clear path to assuring that the caller asserting the identity is indeed e= ntitled to claim control of that number (well, SPs mostly, not the caller, = at least initially). There is no equivalent assurance for CNAM. =20 >=20 > I don't want to get into a fight over which database is better, but the a= lternate, doesn't depend on the origination carrier mechansism is statisica= lly actually a better "validation" of the content than what a traditional c= arrier gets in his service order (because they usually don't actually valid= ate the content), and is infiniately better than the carriers that allow th= e consumer to put anything they want in the database. Without a reasonable= way to assure that the database is actually valid, what is the value of ca= rrying an assertion? >=20 > If we had such a mechanism, what prevents one of the carriers that let's = you put anything you want in the database from asserting that the content o= f P-A-ID is valid, when the user is allowed to say whatever they want goes = in P-A-ID? >=20 > The best thing I can come up with would be to have some independent valid= ation service that used other data sources to validate the content, and let= them sign it. Then we could carry that signature somewhere.=20 >=20 > Right now, I think we should leave it out of scope. If we can figure out= a way to do validation, then we can revisit the notion of carrying evidenc= e of validation in future work. >=20 > Does argue for making sure that whatever mechanism we arrive at should ha= ve some obvious extension mechanism, perhaps along the lines of what Jon wa= s suggesting for media properties. If you recall, he proposed to have a di= gest of SDP where the digest was protected by the signature, but if the SDP= received didn't match the SDP sent, the termination side could know that, = but the basic identity mechanism could succeed anyway (that is, you knew yo= u had a valid identity and a modified SDP). >=20 > Brian >=20 > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > Would it be possible to provide an indication of whether the calling name= was validated (in the same sense that the calling number was validated, bu= t an independent indication)? >=20 > =20 >=20 > ISTM that should be a simple exercise, protocol-wise. And it maintains t= he parallel treatment of name and number that we have today (e.g., there ar= e today separate indications of privacy, for name and number). But that's = not my main concern; mostly I'm thinking of the evolution of the process by= which calling name is provided. Even if it's not possible to validate cal= ling name as provided by CNAM, it might be possible to validate calling nam= e as provided by other methods; e.g., by the calling network in the display= -name header field in the FROM or (more likely in public networks) the P-A-= ID header. >=20 > =20 >=20 > tim >=20 > =20 >=20 > =20 >=20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of P= FAUTZ, PENN L > Sent: Wednesday, August 14, 2013 9:37 AM > To: Brian Rosen; Hadriel Kaplan > Cc: stir@ietf.org; Paul Kyzivat > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) >=20 > =20 >=20 > I assume the concern in this thread is with the case where a number might= be authenticated but the CNAM displayed would be misleading because of lax= policies of the CNAM provider - e.g., the bad guy makes a call from what i= s indeed his legit number but has managed to get Bank of America into his C= NAM entry. >=20 > =20 >=20 > I'm thinking that taking on CNAM in the ietf may be a bridge too far for = stir. Leave what happens after the number is validated up to national autho= rities since arrangements may differ. And at least in the case above it sho= uld be possible to trace back to the perp. >=20 > =20 >=20 > More generally I think the object of stir ought to be just to provide the= customer an indication of whether the calling number was validated on not = - whether calls get blocked or unvalidated numbers are still displayed shou= ld be up to the customer and their service provider. >=20 > =20 >=20 > Penn Pfautz >=20 > AT&T Access Management >=20 > +1-732-420-4962 >=20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of B= rian Rosen > Sent: Wednesday, August 14, 2013 9:32 AM > To: Hadriel Kaplan > Cc: stir@ietf.org; Paul Kyzivat > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) >=20 > =20 >=20 > I think we probably should keep CNAM out of this for now anyway. >=20 > =20 >=20 > The advantage of the credential delegation process as we have defined it = is that it's authoritative. >=20 > =20 >=20 > The current CNAM databases cannot be called "authoritative" really. Clas= sically, as you describe, there is a database operated by on on behalf of t= he origination carrier and queried by the termination carrier (often with a= charge to query). The content is what the carrier has recorde from the or= iginal service order, but there isn't any attempt to validate those names, = and there are carriers who will let you put anything you like in there. Ho= w "authoritative" is that? Then there are other databases, like Neustar's,= that don't have any relationship to the originination carrier - the termin= ation carrier dips an independently developed database of name-number relat= ionships. These databases are developed using a wide variety of sources an= d have evolved to be very accurate, but hardly "authoritative". >=20 > =20 >=20 > And yes, Hadriel, there are regulatory restrictions, mostly about what th= e NPAC (number portability database administrator) can do. The CNAM databas= es have very few regulations to deal with. >=20 > =20 >=20 > Brian=20 >=20 >=20 > On Wednesday, August 14, 2013, Hadriel Kaplan wrote: >=20 >=20 > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Thu Aug 15 12:39:36 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FADB11E80AD for ; Thu, 15 Aug 2013 12:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, FRT_PENIS1=3.592, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiq7M-cDa06m for ; Thu, 15 Aug 2013 12:39:31 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id D5B1411E80EE for ; Thu, 15 Aug 2013 12:39:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 15 Aug 2013 19:39:29 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,887,1367971200"; d="scan'208";a="537525188" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 15 Aug 2013 19:39:19 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Thu, 15 Aug 2013 15:39:19 -0400 To: Henning Schulzrinne , 'Paul Kyzivat' , Brian Rosen Date: Thu, 15 Aug 2013 15:39:18 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbCAAZhJ4A== Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> 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 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:39:36 -0000 With respect, I think statements like " I don't see how signing helps " put= the cart before the horse. Signing is an attribute of a possible solution= , not a requirement. =20 It is precisely the www.callerid4u.com scenario you note, that worries me. = ISTM that if we declare any sort of validation for calling name to be out = of scope, we provide no solution to the victims of scams enabled by service= s that allow dishonest actors to associate the name of a bank with their ph= one number. I recognize that names are not delegated in the same way that numbers are, = and that there are all sorts of semantic nuances that make their validation= difficult. Still, CA's do it. And it's been proposed on this list that a= smartphone app could do it. So I don't see why we're so quick to agree we= can't do it. Or at least, do something. =20 I'm a pragmatist. Maybe we can't do as good a job validating names as we c= an numbers. I still think it's better to make things better than to do not= hing. For example ISTM it'd be positive progress to enable the called part= y to make a more informed decision about whether to trust the calling name,= than he can today. tim p.s. I tend to agree with Rich, that we can't forever duck the issue of wha= t gets presented to the called party. Whether it's addressed directly or n= ot, we're already making assumptions about what is and isn't reasonable. =20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Wednesday, August 14, 2013 2:19 PM To: 'Paul Kyzivat'; Brian Rosen Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Just piling on... There are at least three levels of information here, maki= ng it difficult to do that within the signaling framework: * the name of the person calling (vs. the subscriber name) * the name of the organization * properties of the organization ("licensed plumber", "FDIC-insured bank", = "located in Washington, DC", "registered charity") This is more whois-like information than just the SIP display name. In the = certificate space, we have two levels: (1) assertion of domain name control= ; (2) EV (extended validation) certs. It would be interesting to see how we= ll the EV concept has worked out in practice. I don't see how signing helps here at all, for the reasons mentioned. Nefar= ious actors can use services such as http://www.callerid4u.com/ to use a le= gitimate number with just about any name string. And for corporate accounts= , the service provider has no way of knowing whether Tom Sawyer is really a= t a particular number in a range and whether that entity prefers to list th= e name of the person, just the organization, the location ("PizzaHut Leonia= ") or something else. Indeed, the same number can legitimately have multipl= e display names that change quickly over time (e.g., staff at the doctor's = office). Verifiable whois-like information could be very useful and service provider= s could see that as an opportunity, given that they do know a lot about the= ir customers, such as their billing and service address and how long they h= ave been in business. But it's a separate problem, probably more closely re= lated to the number allocation problem. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Wednesday, August 14, 2013 3:04 PM To: Brian Rosen Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On 8/14/13 8:38 PM, Brian Rosen wrote: > I suppose it's possible, but what is the criteria for validation? > > With TNs, we have credentials that accompany number delegation - we=20 > have a clear path to assuring that the caller asserting the identity=20 > is indeed entitled to claim control of that number (well, SPs mostly,=20 > not the caller, at least initially). There is no equivalent assurance=20 > for CNAM. > > I don't want to get into a fight over which database is better, but=20 > the alternate, doesn't depend on the origination carrier mechansism is=20 > statisically actually a better "validation" of the content than what a=20 > traditional carrier gets in his service order (because they usually=20 > don't actually validate the content), and is infiniately better than=20 > the carriers that allow the consumer to put anything they want in the=20 > database. Without a reasonable way to assure that the database is=20 > actually valid, what is the value of carrying an assertion? While I recognize that letting the customer put in whatever they want is pr= oblematic, I have no idea whether the alternative of letting the CNAM provi= der include whatever they want is "better". (How would we measure that?) (I've just been trying to deal with an "information aggregator" that is pub= lishing wrong information about me and won't change it. So I'm not feeling = good about that sort of thing.) ISTM that is is yet another example of ancient, informal, manual systems, t= hat once mostly "worked" based on the good will of the people involved, but= that have now been automated into monstrosities that nobody understands. (= Management of healthcare data is another example.) Ultimately there will need to be a big effort to develop a formal framework= for this. And it will probably require the creation of new laws. Alternatively this could be left to the open market. (E.g., The callee coul= d just Google the calling number.) In any case STIR can't go down this rat hole. Thanks, Paul > If we had such a mechanism, what prevents one of the carriers that=20 > let's you put anything you want in the database from asserting that=20 > the content of P-A-ID is valid, when the user is allowed to say=20 > whatever they want goes in P-A-ID? > > The best thing I can come up with would be to have some independent=20 > validation service that used other data sources to validate the=20 > content, and let them sign it. Then we could carry that signature somewh= ere. > > Right now, I think we should leave it out of scope. If we can figure=20 > out a way to do validation, then we can revisit the notion of carrying=20 > evidence of validation in future work. > > Does argue for making sure that whatever mechanism we arrive at should=20 > have some obvious extension mechanism, perhaps along the lines of what=20 > Jon was suggesting for media properties. If you recall, he proposed=20 > to have a digest of SDP where the digest was protected by the=20 > signature, but if the SDP received didn't match the SDP sent, the=20 > termination side could know that, but the basic identity mechanism=20 > could succeed anyway (that is, you knew you had a valid identity and a mo= dified SDP). > > Brian > > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > > Would it be possible to provide an indication of whether the calling > name was validated (in the same sense that the calling number was > validated, but an independent indication)?____ > > __ __ > > ISTM that should be a simple exercise, protocol-wise. And it > maintains the parallel treatment of name and number that we have > today (e.g., there are today separate indications of privacy, for > name and number). But that's not my main concern; mostly I'm > thinking of the evolution of the process by which calling name is > provided. Even if it's not possible to validate calling name as > provided by CNAM, it might be possible to validate calling name as > provided by other methods; e.g., by the calling network in the > display-name header field in the FROM or (more likely in public > networks) the P-A-ID header.____ > > __ __ > > tim____ > > __ __ > > __ __ > > *From:*stir-bounces@ietf.org 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org > ] *On Behalf Of > *PFAUTZ, PENN L > *Sent:* Wednesday, August 14, 2013 9:37 AM > *To:* Brian Rosen; Hadriel Kaplan > *Cc:* stir@ietf.org ; > Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I assume the concern in this thread is with the case where a number > might be authenticated but the CNAM displayed would be misleading > because of lax policies of the CNAM provider - e.g., the bad guy > makes a call from what is indeed his legit number but has managed to > get Bank of America into his CNAM entry.____ > > __ __ > > I'm thinking that taking on CNAM in the ietf may be a bridge too far > for stir. Leave what happens after the number is validated up to > national authorities since arrangements may differ. And at least in > the case above it should be possible to trace back to the=20 > perp.____ > > __ __ > > More generally I think the object of stir ought to be just to > provide the customer an indication of whether the calling number was > validated on not - whether calls get blocked or unvalidated numbers > are still displayed should be up to the customer and their service > provider.____ > > __ __ > > Penn Pfautz____ > > AT&T Access Management____ > > +1-732-420-4962____ > > *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On > Behalf Of *Brian Rosen > *Sent:* Wednesday, August 14, 2013 9:32 AM > *To:* Hadriel Kaplan > *Cc:* stir@ietf.org; Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I think we probably should keep CNAM out of this for now=20 > anyway.____ > > __ __ > > The advantage of the credential delegation process as we have > defined it is that it's authoritative.____ > > __ __ > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on > on behalf of the origination carrier and queried by the termination > carrier (often with a charge to query). The content is what the > carrier has recorde from the original service order, but there isn't > any attempt to validate those names, and there are carriers who will > let you put anything you like in there. How "authoritative" is > that? Then there are other databases, like Neustar's, that don't > have any relationship to the originination carrier - the termination > carrier dips an independently developed database of name-number > relationships. These databases are developed using a wide variety > of sources and have evolved to be very accurate, but hardly > "authoritative".____ > > __ __ > > And yes, Hadriel, there are regulatory restrictions, mostly about > what the NPAC (number portability database administrator) can do. > The CNAM databases have very few regulations to deal with.____ > > __ __ > > Brian ____ > > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From kent@bbn.com Thu Aug 15 12:52:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7FB11E8167 for ; Thu, 15 Aug 2013 12:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhI-a2SWGre8 for ; Thu, 15 Aug 2013 12:52:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 459F711E8151 for ; Thu, 15 Aug 2013 12:52:51 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53455) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VA3bF-0007NH-Cu for stir@ietf.org; Thu, 15 Aug 2013 15:52:49 -0400 Message-ID: <520D3191.1090703@bbn.com> Date: Thu, 15 Aug 2013 15:52:49 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3A08@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3A08@FHDP1LUMXC7V31.us.one.verizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:52:57 -0000 Dwight, I think the concern is that it's hard to image an appropriate, authoritative source of this type of caller ID info. We have a great, worked example of how not to do this in the browser environment (the current web PKI), and a work-in-progress on how to do it right for that environment (DANE). But the DANE model doesn't work well for the sort of names one typically sees displayed for Caller ID. Steve From Henning.Schulzrinne@fcc.gov Thu Aug 15 14:06:44 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03711E810C for ; Thu, 15 Aug 2013 14:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SSncQqSjrFl for ; Thu, 15 Aug 2013 14:06:40 -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 4E8AB11E81B7 for ; Thu, 15 Aug 2013 14:06:39 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'Dwight, Timothy M (Tim)'" , 'Paul Kyzivat' , Brian Rosen Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbCAAZhJ4IAAFt9A Date: Thu, 15 Aug 2013 21:06:37 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 21:06:44 -0000 I fully agree that trustworthy information about the caller (identity, pref= erably beyond what fits into 15 characters) is a worthy goal, but tradition= al caller ID may just be too limited for that purpose. The problem is that I don't see a good way to do this by signing. There are= three cases I can see: * #1: Bad (spoofed) number, spoofed text --> STIR will flag that and presum= ably lead recipients to ignore or question both; * #2: Good (signed) number, spoofed text: this should only occur if there's= a MITM attack where somebody replaces (say) the personal name with a misle= ading one ("John Doe" becomes "Bank of America") * #3: Dodgy or careless provider: the number is legitimately assigned and s= igned, but the provider allows the caller to insert any textual information= they want, either on-a-call-by-call basis or when signing up for service i= nitially. As noted by others, signing doesn't help here, but you can at lea= st identify the perpetrator and there is private recourse, such as trademar= k violations, that are not available for number spoofing. Given that we've largely declared MITM and call hijacking to be out of (ini= tial) STIR scope and that this attack vector seems somewhat unlikely in pra= ctice, that leaves case #3. I do see one potential hijack attack that we might want to and can prevent,= namely the copy-paste attack, where somebody has access to legitimate inbo= und calls, signed, and then re-issues the call with a spoofed textual infor= mation, assuming they don't care about the originating number (which would = be the case for phishing attacks). That requires very little effort for the= SIP case, and might argue for cryptographically including the text in a si= gnature, which simply asserts that the same entity that signed the number a= lso saw the same text, whatever its legal validity might be. If end users a= re allowed to sign, this doesn't help much, since they can just use case #3= . For traditional CA-issue web certs (not the EV variety), you can pretty muc= h put anything in the organization name and the location, and you'll get is= sued a cert that includes that information. The only proof is that the hold= er has operative control of the domain name that's in the cert. This does not apply to the CNAM case, just the inband display name case; CN= AM seems similar to the "dodgy/careless" case above. Henning -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Thursday, August 15, 2013 3:39 PM To: Henning Schulzrinne; 'Paul Kyzivat'; Brian Rosen Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) With respect, I think statements like " I don't see how signing helps " put= the cart before the horse. Signing is an attribute of a possible solution= , not a requirement. =20 It is precisely the www.callerid4u.com scenario you note, that worries me. = ISTM that if we declare any sort of validation for calling name to be out = of scope, we provide no solution to the victims of scams enabled by service= s that allow dishonest actors to associate the name of a bank with their ph= one number. I recognize that names are not delegated in the same way that numbers are, = and that there are all sorts of semantic nuances that make their validation= difficult. Still, CA's do it. And it's been proposed on this list that a= smartphone app could do it. So I don't see why we're so quick to agree we= can't do it. Or at least, do something. =20 I'm a pragmatist. Maybe we can't do as good a job validating names as we c= an numbers. I still think it's better to make things better than to do not= hing. For example ISTM it'd be positive progress to enable the called part= y to make a more informed decision about whether to trust the calling name,= than he can today. tim p.s. I tend to agree with Rich, that we can't forever duck the issue of wha= t gets presented to the called party. Whether it's addressed directly or n= ot, we're already making assumptions about what is and isn't reasonable. =20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Wednesday, August 14, 2013 2:19 PM To: 'Paul Kyzivat'; Brian Rosen Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Just piling on... There are at least three levels of information here, maki= ng it difficult to do that within the signaling framework: * the name of the person calling (vs. the subscriber name) * the name of the organization * properties of the organization ("licensed plumber", "FDIC-insured bank", = "located in Washington, DC", "registered charity") This is more whois-like information than just the SIP display name. In the = certificate space, we have two levels: (1) assertion of domain name control= ; (2) EV (extended validation) certs. It would be interesting to see how we= ll the EV concept has worked out in practice. I don't see how signing helps here at all, for the reasons mentioned. Nefar= ious actors can use services such as http://www.callerid4u.com/ to use a le= gitimate number with just about any name string. And for corporate accounts= , the service provider has no way of knowing whether Tom Sawyer is really a= t a particular number in a range and whether that entity prefers to list th= e name of the person, just the organization, the location ("PizzaHut Leonia= ") or something else. Indeed, the same number can legitimately have multipl= e display names that change quickly over time (e.g., staff at the doctor's = office). Verifiable whois-like information could be very useful and service provider= s could see that as an opportunity, given that they do know a lot about the= ir customers, such as their billing and service address and how long they h= ave been in business. But it's a separate problem, probably more closely re= lated to the number allocation problem. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Wednesday, August 14, 2013 3:04 PM To: Brian Rosen Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On 8/14/13 8:38 PM, Brian Rosen wrote: > I suppose it's possible, but what is the criteria for validation? > > With TNs, we have credentials that accompany number delegation - we=20 > have a clear path to assuring that the caller asserting the identity=20 > is indeed entitled to claim control of that number (well, SPs mostly,=20 > not the caller, at least initially). There is no equivalent assurance=20 > for CNAM. > > I don't want to get into a fight over which database is better, but=20 > the alternate, doesn't depend on the origination carrier mechansism is=20 > statisically actually a better "validation" of the content than what a=20 > traditional carrier gets in his service order (because they usually=20 > don't actually validate the content), and is infiniately better than=20 > the carriers that allow the consumer to put anything they want in the=20 > database. Without a reasonable way to assure that the database is=20 > actually valid, what is the value of carrying an assertion? While I recognize that letting the customer put in whatever they want is pr= oblematic, I have no idea whether the alternative of letting the CNAM provi= der include whatever they want is "better". (How would we measure that?) (I've just been trying to deal with an "information aggregator" that is pub= lishing wrong information about me and won't change it. So I'm not feeling = good about that sort of thing.) ISTM that is is yet another example of ancient, informal, manual systems, t= hat once mostly "worked" based on the good will of the people involved, but= that have now been automated into monstrosities that nobody understands. (= Management of healthcare data is another example.) Ultimately there will need to be a big effort to develop a formal framework= for this. And it will probably require the creation of new laws. Alternatively this could be left to the open market. (E.g., The callee coul= d just Google the calling number.) In any case STIR can't go down this rat hole. Thanks, Paul > If we had such a mechanism, what prevents one of the carriers that=20 > let's you put anything you want in the database from asserting that=20 > the content of P-A-ID is valid, when the user is allowed to say=20 > whatever they want goes in P-A-ID? > > The best thing I can come up with would be to have some independent=20 > validation service that used other data sources to validate the=20 > content, and let them sign it. Then we could carry that signature somewh= ere. > > Right now, I think we should leave it out of scope. If we can figure=20 > out a way to do validation, then we can revisit the notion of carrying=20 > evidence of validation in future work. > > Does argue for making sure that whatever mechanism we arrive at should=20 > have some obvious extension mechanism, perhaps along the lines of what=20 > Jon was suggesting for media properties. If you recall, he proposed=20 > to have a digest of SDP where the digest was protected by the=20 > signature, but if the SDP received didn't match the SDP sent, the=20 > termination side could know that, but the basic identity mechanism=20 > could succeed anyway (that is, you knew you had a valid identity and a mo= dified SDP). > > Brian > > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > > Would it be possible to provide an indication of whether the calling > name was validated (in the same sense that the calling number was > validated, but an independent indication)?____ > > __ __ > > ISTM that should be a simple exercise, protocol-wise. And it > maintains the parallel treatment of name and number that we have > today (e.g., there are today separate indications of privacy, for > name and number). But that's not my main concern; mostly I'm > thinking of the evolution of the process by which calling name is > provided. Even if it's not possible to validate calling name as > provided by CNAM, it might be possible to validate calling name as > provided by other methods; e.g., by the calling network in the > display-name header field in the FROM or (more likely in public > networks) the P-A-ID header.____ > > __ __ > > tim____ > > __ __ > > __ __ > > *From:*stir-bounces@ietf.org 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org > ] *On Behalf Of > *PFAUTZ, PENN L > *Sent:* Wednesday, August 14, 2013 9:37 AM > *To:* Brian Rosen; Hadriel Kaplan > *Cc:* stir@ietf.org ; > Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I assume the concern in this thread is with the case where a number > might be authenticated but the CNAM displayed would be misleading > because of lax policies of the CNAM provider - e.g., the bad guy > makes a call from what is indeed his legit number but has managed to > get Bank of America into his CNAM entry.____ > > __ __ > > I'm thinking that taking on CNAM in the ietf may be a bridge too far > for stir. Leave what happens after the number is validated up to > national authorities since arrangements may differ. And at least in > the case above it should be possible to trace back to the=20 > perp.____ > > __ __ > > More generally I think the object of stir ought to be just to > provide the customer an indication of whether the calling number was > validated on not - whether calls get blocked or unvalidated numbers > are still displayed should be up to the customer and their service > provider.____ > > __ __ > > Penn Pfautz____ > > AT&T Access Management____ > > +1-732-420-4962____ > > *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On > Behalf Of *Brian Rosen > *Sent:* Wednesday, August 14, 2013 9:32 AM > *To:* Hadriel Kaplan > *Cc:* stir@ietf.org; Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I think we probably should keep CNAM out of this for now=20 > anyway.____ > > __ __ > > The advantage of the credential delegation process as we have > defined it is that it's authoritative.____ > > __ __ > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on > on behalf of the origination carrier and queried by the termination > carrier (often with a charge to query). The content is what the > carrier has recorde from the original service order, but there isn't > any attempt to validate those names, and there are carriers who will > let you put anything you like in there. How "authoritative" is > that? Then there are other databases, like Neustar's, that don't > have any relationship to the originination carrier - the termination > carrier dips an independently developed database of name-number > relationships. These databases are developed using a wide variety > of sources and have evolved to be very accurate, but hardly > "authoritative".____ > > __ __ > > And yes, Hadriel, there are regulatory restrictions, mostly about > what the NPAC (number portability database administrator) can do. > The CNAM databases have very few regulations to deal with.____ > > __ __ > > Brian ____ > > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Thu Aug 15 14:25:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E83C11E8192 for ; Thu, 15 Aug 2013 14:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.384 X-Spam-Level: X-Spam-Status: No, score=-99.384 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZwC05Ao6YT6 for ; Thu, 15 Aug 2013 14:25:29 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id B69C111E8118 for ; Thu, 15 Aug 2013 14:25:29 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so1255476pbb.33 for ; Thu, 15 Aug 2013 14:25:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s9Wp5JPnQn8kSIQjpZPkhMpw1Iuk8lB16FJB/XUjNZA=; b=NZ8rH5lIV+lLVmefCSlhb+cZSq4RGXDvXOixdJkYb5mh4nuKKNPZHKYcPEZSWF8Gos Ab2kyTTRlWp28fhUbmGEsmNu2Gp6YC74RnAQ5mqvFB3MA2iEF0ZEeNeJdeDhuWOxdmN1 tWPDFDxD0aoPHvMe7tvPxHUhInZ7FIjdUQPg/pm/7uW0PL5vYPh/ppkQr2YvkvsgOnhy SOzETp70tNK5/IKQFQC25n5hGF9Lk1xN96BxlrIN4swIsTuXrlkEUeQiV5igR7Tm596S 0iYk2hWm64VoGF08C0fJoKObAkOy0BbUUAdcOI1/vzfsDW8b3pBeWtY54iJqJX+/TQZ6 xyhA== X-Gm-Message-State: ALoCoQl6PNK/peOndS4KYKiiOpEU26buVawNTTlGkPOBd26A0FXQK+IanCApG875Go6PvLi+FkL1 MIME-Version: 1.0 X-Received: by 10.69.0.129 with SMTP id ay1mr5947481pbd.12.1376601929327; Thu, 15 Aug 2013 14:25:29 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Thu, 15 Aug 2013 14:25:29 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.com> Date: Thu, 15 Aug 2013 17:25:29 -0400 Message-ID: From: Brian Rosen To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=047d7b2e3e68feb70004e4031c45 Cc: "stir@ietf.org" , "Dwight, Timothy M \(Tim\)" , Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 21:25:43 -0000 --047d7b2e3e68feb70004e4031c45 Content-Type: text/plain; charset=ISO-8859-1 With respect to caller ID, at least at present, the caller id that is usually presented to the user comes from a database as a result of a query. The SIP signaling protocol provides ways to carry the information, but the data the user sees is generally the result of a CNAM dip. That dip is done on the termination side. Now, that is certainly more true of legacy wireline/wireless than VoIP endpoints, but lots of VoIP endpoints do in fact display the result of the CNAM dip one way or another. We can try to change that - we can try to change to using the data carried in the call, set by the origination side and used by the termination side. As long as there is a charge by the origination network to get the CNAM data levied on the termination network, obsoleting those databases may be hard. The databases that use independently validated name-number associations exist to avoid paying that charge. They also generally are more accurate because the opportunities for fraud are significantly reduced, but they are not as comprehensive (generally, the CNAM directories have entries for each and every TN served by a carrier. If we changed the way the data is delivered to the termination endpoint, then we would have to consider how to assure that it's valid, and not messed with (MITM). The former is the difficulty we have. So, are you thinking we could reasonably change the entire CNAM ecosystem? If you think that is feasible, than we can talk about what mechanisms might be appropriate. Brian On Thu, Aug 15, 2013 at 5:06 PM, Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> wrote: > I fully agree that trustworthy information about the caller (identity, > preferably beyond what fits into 15 characters) is a worthy goal, but > traditional caller ID may just be too limited for that purpose. > > The problem is that I don't see a good way to do this by signing. There > are three cases I can see: > > * #1: Bad (spoofed) number, spoofed text --> STIR will flag that and > presumably lead recipients to ignore or question both; > > * #2: Good (signed) number, spoofed text: this should only occur if > there's a MITM attack where somebody replaces (say) the personal name with > a misleading one ("John Doe" becomes "Bank of America") > > * #3: Dodgy or careless provider: the number is legitimately assigned and > signed, but the provider allows the caller to insert any textual > information they want, either on-a-call-by-call basis or when signing up > for service initially. As noted by others, signing doesn't help here, but > you can at least identify the perpetrator and there is private recourse, > such as trademark violations, that are not available for number spoofing. > > Given that we've largely declared MITM and call hijacking to be out of > (initial) STIR scope and that this attack vector seems somewhat unlikely in > practice, that leaves case #3. > > I do see one potential hijack attack that we might want to and can > prevent, namely the copy-paste attack, where somebody has access to > legitimate inbound calls, signed, and then re-issues the call with a > spoofed textual information, assuming they don't care about the originating > number (which would be the case for phishing attacks). That requires very > little effort for the SIP case, and might argue for cryptographically > including the text in a signature, which simply asserts that the same > entity that signed the number also saw the same text, whatever its legal > validity might be. If end users are allowed to sign, this doesn't help > much, since they can just use case #3. > > For traditional CA-issue web certs (not the EV variety), you can pretty > much put anything in the organization name and the location, and you'll get > issued a cert that includes that information. The only proof is that the > holder has operative control of the domain name that's in the cert. > > This does not apply to the CNAM case, just the inband display name case; > CNAM seems similar to the "dodgy/careless" case above. > > Henning > > -----Original Message----- > From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] > Sent: Thursday, August 15, 2013 3:39 PM > To: Henning Schulzrinne; 'Paul Kyzivat'; Brian Rosen > Cc: stir@ietf.org > Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) > > With respect, I think statements like " I don't see how signing helps " > put the cart before the horse. Signing is an attribute of a possible > solution, not a requirement. > > It is precisely the www.callerid4u.com scenario you note, that worries > me. ISTM that if we declare any sort of validation for calling name to be > out of scope, we provide no solution to the victims of scams enabled by > services that allow dishonest actors to associate the name of a bank with > their phone number. > > I recognize that names are not delegated in the same way that numbers are, > and that there are all sorts of semantic nuances that make their validation > difficult. Still, CA's do it. And it's been proposed on this list that a > smartphone app could do it. So I don't see why we're so quick to agree we > can't do it. Or at least, do something. > > I'm a pragmatist. Maybe we can't do as good a job validating names as we > can numbers. I still think it's better to make things better than to do > nothing. For example ISTM it'd be positive progress to enable the called > party to make a more informed decision about whether to trust the calling > name, than he can today. > > tim > > p.s. I tend to agree with Rich, that we can't forever duck the issue of > what gets presented to the called party. Whether it's addressed directly > or not, we're already making assumptions about what is and isn't reasonable. > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Wednesday, August 14, 2013 2:19 PM > To: 'Paul Kyzivat'; Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > Just piling on... There are at least three levels of information here, > making it difficult to do that within the signaling framework: > > * the name of the person calling (vs. the subscriber name) > * the name of the organization > * properties of the organization ("licensed plumber", "FDIC-insured bank", > "located in Washington, DC", "registered charity") > > This is more whois-like information than just the SIP display name. In the > certificate space, we have two levels: (1) assertion of domain name > control; (2) EV (extended validation) certs. It would be interesting to see > how well the EV concept has worked out in practice. > > I don't see how signing helps here at all, for the reasons mentioned. > Nefarious actors can use services such as http://www.callerid4u.com/ to > use a legitimate number with just about any name string. And for corporate > accounts, the service provider has no way of knowing whether Tom Sawyer is > really at a particular number in a range and whether that entity prefers to > list the name of the person, just the organization, the location ("PizzaHut > Leonia") or something else. Indeed, the same number can legitimately have > multiple display names that change quickly over time (e.g., staff at the > doctor's office). > > Verifiable whois-like information could be very useful and service > providers could see that as an opportunity, given that they do know a lot > about their customers, such as their billing and service address and how > long they have been in business. But it's a separate problem, probably more > closely related to the number allocation problem. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, August 14, 2013 3:04 PM > To: Brian Rosen > Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > On 8/14/13 8:38 PM, Brian Rosen wrote: > > I suppose it's possible, but what is the criteria for validation? > > > > With TNs, we have credentials that accompany number delegation - we > > have a clear path to assuring that the caller asserting the identity > > is indeed entitled to claim control of that number (well, SPs mostly, > > not the caller, at least initially). There is no equivalent assurance > > for CNAM. > > > > I don't want to get into a fight over which database is better, but > > the alternate, doesn't depend on the origination carrier mechansism is > > statisically actually a better "validation" of the content than what a > > traditional carrier gets in his service order (because they usually > > don't actually validate the content), and is infiniately better than > > the carriers that allow the consumer to put anything they want in the > > database. Without a reasonable way to assure that the database is > > actually valid, what is the value of carrying an assertion? > > While I recognize that letting the customer put in whatever they want is > problematic, I have no idea whether the alternative of letting the CNAM > provider include whatever they want is "better". (How would we measure > that?) > > (I've just been trying to deal with an "information aggregator" that is > publishing wrong information about me and won't change it. So I'm not > feeling good about that sort of thing.) > > ISTM that is is yet another example of ancient, informal, manual systems, > that once mostly "worked" based on the good will of the people involved, > but that have now been automated into monstrosities that nobody > understands. (Management of healthcare data is another example.) > > Ultimately there will need to be a big effort to develop a formal > framework for this. And it will probably require the creation of new laws. > > Alternatively this could be left to the open market. (E.g., The callee > could just Google the calling number.) > > In any case STIR can't go down this rat hole. > > Thanks, > Paul > > > If we had such a mechanism, what prevents one of the carriers that > > let's you put anything you want in the database from asserting that > > the content of P-A-ID is valid, when the user is allowed to say > > whatever they want goes in P-A-ID? > > > > The best thing I can come up with would be to have some independent > > validation service that used other data sources to validate the > > content, and let them sign it. Then we could carry that signature > somewhere. > > > > Right now, I think we should leave it out of scope. If we can figure > > out a way to do validation, then we can revisit the notion of carrying > > evidence of validation in future work. > > > > Does argue for making sure that whatever mechanism we arrive at should > > have some obvious extension mechanism, perhaps along the lines of what > > Jon was suggesting for media properties. If you recall, he proposed > > to have a digest of SDP where the digest was protected by the > > signature, but if the SDP received didn't match the SDP sent, the > > termination side could know that, but the basic identity mechanism > > could succeed anyway (that is, you knew you had a valid identity and a > modified SDP). > > > > Brian > > > > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > > > > Would it be possible to provide an indication of whether the calling > > name was validated (in the same sense that the calling number was > > validated, but an independent indication)?____ > > > > __ __ > > > > ISTM that should be a simple exercise, protocol-wise. And it > > maintains the parallel treatment of name and number that we have > > today (e.g., there are today separate indications of privacy, for > > name and number). But that's not my main concern; mostly I'm > > thinking of the evolution of the process by which calling name is > > provided. Even if it's not possible to validate calling name as > > provided by CNAM, it might be possible to validate calling name as > > provided by other methods; e.g., by the calling network in the > > display-name header field in the FROM or (more likely in public > > networks) the P-A-ID header.____ > > > > __ __ > > > > tim____ > > > > __ __ > > > > __ __ > > > > *From:*stir-bounces@ietf.org > 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org > > ] *On Behalf Of > > *PFAUTZ, PENN L > > *Sent:* Wednesday, August 14, 2013 9:37 AM > > *To:* Brian Rosen; Hadriel Kaplan > > *Cc:* stir@ietf.org ; > > Paul Kyzivat > > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > > Charter)____ > > > > __ __ > > > > I assume the concern in this thread is with the case where a number > > might be authenticated but the CNAM displayed would be misleading > > because of lax policies of the CNAM provider - e.g., the bad guy > > makes a call from what is indeed his legit number but has managed to > > get Bank of America into his CNAM entry.____ > > > > __ __ > > > > I'm thinking that taking on CNAM in the ietf may be a bridge too far > > for stir. Leave what happens after the number is validated up to > > national authorities since arrangements may differ. And at least in > > the case above it should be possible to trace back to the > > perp.____ > > > > __ __ > > > > More generally I think the object of stir ought to be just to > > provide the customer an indication of whether the calling number was > > validated on not - whether calls get blocked or unvalidated numbers > > are still displayed should be up to the customer and their service > > provider.____ > > > > __ __ > > > > Penn Pfautz____ > > > > AT&T Access Management____ > > > > +1-732-420-4962____ > > > > *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On > > Behalf Of *Brian Rosen > > *Sent:* Wednesday, August 14, 2013 9:32 AM > > *To:* Hadriel Kaplan > > *Cc:* stir@ietf.org; Paul Kyzivat > > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > > Charter)____ > > > > __ __ > > > > I think we probably should keep CNAM out of this for now > > anyway.____ > > > > __ __ > > > > The advantage of the credential delegation process as we have > > defined it is that it's authoritative.____ > > > > __ __ > > > > The current CNAM databases cannot be called "authoritative" really. > > Classically, as you describe, there is a database operated by on > > on behalf of the origination carrier and queried by the termination > > carrier (often with a charge to query). The content is what the > > carrier has recorde from the original service order, but there isn't > > any attempt to validate those names, and there are carriers who will > > let you put anything you like in there. How "authoritative" is > > that? Then there are other databases, like Neustar's, that don't > > have any relationship to the originination carrier - the termination > > carrier dips an independently developed database of name-number > > relationships. These databases are developed using a wide variety > > of sources and have evolved to be very accurate, but hardly > > "authoritative".____ > > > > __ __ > > > > And yes, Hadriel, there are regulatory restrictions, mostly about > > what the NPAC (number portability database administrator) can do. > > The CNAM databases have very few regulations to deal with.____ > > > > __ __ > > > > Brian ____ > > > > > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ > > > > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7b2e3e68feb70004e4031c45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
With respect to caller ID, at least at present, the caller= id that is usually presented to the user comes from a database as a result= of a query. =A0The SIP signaling protocol provides ways to carry the infor= mation, but the data the user sees is generally the result of a CNAM dip. = =A0That dip is done on the termination side.

Now, that is certainly more true of legacy wireline/wireless= than VoIP endpoints, but lots of VoIP endpoints do in fact display the res= ult of the CNAM dip one way or another.

We can try= to change that - we can try to change to using the data carried in the cal= l, set by the origination side and used by the termination side.

As long as there is a charge by the origination network= to get the CNAM data levied on the termination network, obsoleting those d= atabases may be hard. =A0The databases that use independently validated nam= e-number associations exist to avoid paying that charge. =A0They also gener= ally are more accurate because the opportunities for fraud are significantl= y reduced, but they are not as comprehensive (generally, the CNAM directori= es have entries for each and every TN served by a carrier.

If we changed the way the data is delivered to the term= ination endpoint, then we would have to consider how to assure that it'= s valid, and not messed with (MITM). =A0The former is the difficulty we hav= e.

So, are you thinking we could reasonably change the ent= ire CNAM ecosystem?

If you think that is feasible,= than we can talk about what mechanisms might be appropriate.

Brian


On Thu, Aug 15, 2013 at 5:06 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:
I fully agree that trustworthy information a= bout the caller (identity, preferably beyond what fits into 15 characters) = is a worthy goal, but traditional caller ID may just be too limited for tha= t purpose.

The problem is that I don't see a good way to do this by signing. There= are three cases I can see:

* #1: Bad (spoofed) number, spoofed text --> STIR will flag that and pre= sumably lead recipients to ignore or question both;

* #2: Good (signed) number, spoofed text: this should only occur if there&#= 39;s a MITM attack where somebody replaces (say) the personal name with a m= isleading one ("John Doe" becomes "Bank of America")
* #3: Dodgy or careless provider: the number is legitimately assigned and s= igned, but the provider allows the caller to insert any textual information= they want, either on-a-call-by-call basis or when signing up for service i= nitially. As noted by others, signing doesn't help here, but you can at= least identify the perpetrator and there is private recourse, such as trad= emark violations, that are not available for number spoofing.

Given that we've largely declared MITM and call hijacking to be out of = (initial) STIR scope and that this attack vector seems somewhat unlikely in= practice, that leaves case #3.

I do see one potential hijack attack that we might want to and can prevent,= namely the copy-paste attack, where somebody has access to legitimate inbo= und calls, signed, and then re-issues the call with a spoofed textual infor= mation, assuming they don't care about the originating number (which wo= uld be the case for phishing attacks). That requires very little effort for= the SIP case, and might argue for cryptographically including the text in = a signature, which simply asserts that the same entity that signed the numb= er also saw the same text, whatever its legal validity might be. If end use= rs are allowed to sign, this doesn't help much, since they can just use= case #3.

For traditional CA-issue web certs (not the EV variety), you can pretty muc= h put anything in the organization name and the location, and you'll ge= t issued a cert that includes that information. The only proof is that the = holder has operative control of the domain name that's in the cert.

This does not apply to the CNAM case, just the inband display name case; CN= AM seems similar to the "dodgy/careless" case above.

Henning

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Thursday, August 15, 2013 3:39 PM
To: Henning Schulzrinne; 'Paul Kyzivat'; Brian Rosen
Cc: stir@ietf.org
Subject: RE: [stir] Early Hom= ework (was Re: Moving from BOF to Charter)

With respect, I think statements like " I don't see how signing he= lps " put the cart before the horse. =A0Signing is an attribute of a p= ossible solution, not a requirement.

It is precisely the www.callerid4u.com scenario you note, that worries me. =A0ISTM that if= we declare any sort of validation for calling name to be out of scope, we = provide no solution to the victims of scams enabled by services that allow = dishonest actors to associate the name of a bank with their phone number.
I recognize that names are not delegated in the same way that numbers are, = and that there are all sorts of semantic nuances that make their validation= difficult. =A0Still, CA's do it. =A0And it's been proposed on this= list that a smartphone app could do it. =A0So I don't see why we'r= e so quick to agree we can't do it. =A0Or at least, do something.

I'm a pragmatist. =A0Maybe we can't do as good a job validating nam= es as we can numbers. =A0I still think it's better to make things bette= r than to do nothing. =A0For example ISTM it'd be positive progress to = enable the called party to make a more informed decision about whether to t= rust the calling name, than he can today.

tim

p.s. I tend to agree with Rich, that we can't forever duck the issue of= what gets presented to the called party. =A0Whether it's addressed dir= ectly or not, we're already making assumptions about what is and isn= 9;t reasonable.


-----Original Message-----
From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] O= n Behalf Of Henning Schulzrinne
Sent: Wednesday, August 14, 2013 2:19 PM
To: 'Paul Kyzivat'; Brian Rosen
Cc: stir@ietf.org
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Just piling on... There are at least three levels of information here, maki= ng it difficult to do that within the signaling framework:

* the name of the person calling (vs. the subscriber name)
* the name of the organization
* properties of the organization ("licensed plumber", "FDIC-= insured bank", "located in Washington, DC", "registered= charity")

This is more whois-like information than just the SIP display name. In the = certificate space, we have two levels: (1) assertion of domain name control= ; (2) EV (extended validation) certs. It would be interesting to see how we= ll the EV concept has worked out in practice.

I don't see how signing helps here at all, for the reasons mentioned. N= efarious actors can use services such as http://www.callerid4u.com/ to use a legitimate n= umber with just about any name string. And for corporate accounts, the serv= ice provider has no way of knowing whether Tom Sawyer is really at a partic= ular number in a range and whether that entity prefers to list the name of = the person, just the organization, the location ("PizzaHut Leonia"= ;) or something else. Indeed, the same number can legitimately have multipl= e display names that change quickly over time (e.g., staff at the doctor= 9;s office).

Verifiable whois-like information could be very useful and service provider= s could see that as an opportunity, given that they do know a lot about the= ir customers, such as their billing and service address and how long they h= ave been in business. But it's a separate problem, probably more closel= y related to the number allocation problem.

-----Original Message-----
From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] O= n Behalf Of Paul Kyzivat
Sent: Wednesday, August 14, 2013 3:04 PM
To: Brian Rosen
Cc: stir@ietf.org; Hadriel Kaplan; Dwi= ght, Timothy M (Tim); PFAUTZ, PENN L
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

On 8/14/13 8:38 PM, Brian Rosen wrote:
> I suppose it's possible, but what is the criteria for validation?<= br> >
> With TNs, we have credentials that accompany number delegation - we > have a clear path to assuring that the caller asserting the identity > is indeed entitled to claim control of that number (well, SPs mostly,<= br> > not the caller, at least initially). =A0There is no equivalent assuran= ce
> for CNAM.
>
> I don't want to get into a fight over which database is better, bu= t
> the alternate, doesn't depend on the origination carrier mechansis= m is
> statisically actually a better "validation" of the content t= han what a
> traditional carrier gets in his service order (because they usually > don't actually validate the content), and is infiniately better th= an
> the carriers that allow the consumer to put anything they want in the<= br> > database. =A0Without a reasonable way to assure that the database is > actually valid, what is the value of carrying an assertion?

While I recognize that letting the customer put in whatever they want is pr= oblematic, I have no idea whether the alternative of letting the CNAM provi= der include whatever they want is "better". (How would we measure=
that?)

(I've just been trying to deal with an "information aggregator&quo= t; that is publishing wrong information about me and won't change it. S= o I'm not feeling good about that sort of thing.)

ISTM that is is yet another example of ancient, informal, manual systems, t= hat once mostly "worked" based on the good will of the people inv= olved, but that have now been automated into monstrosities that nobody unde= rstands. (Management of healthcare data is another example.)

Ultimately there will need to be a big effort to develop a formal framework= for this. And it will probably require the creation of new laws.

Alternatively this could be left to the open market. (E.g., The callee coul= d just Google the calling number.)

In any case STIR can't go down this rat hole.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

> If we had such a mechanism, what prevents one of the carriers that
> let's you put anything you want in the database from asserting tha= t
> the content of P-A-ID is valid, when the user is allowed to say
> whatever they want goes in P-A-ID?
>
> The best thing I can come up with would be to have some independent > validation service that used other data sources to validate the
> content, and let them sign it. =A0Then we could carry that signature s= omewhere.
>
> Right now, I think we should leave it out of scope. =A0If we can figur= e
> out a way to do validation, then we can revisit the notion of carrying=
> evidence of validation in future work.
>
> Does argue for making sure that whatever mechanism we arrive at should=
> have some obvious extension mechanism, perhaps along the lines of what=
> Jon was suggesting for media properties. =A0If you recall, he proposed=
> to have a digest of SDP where the digest was protected by the
> signature, but if the SDP received didn't match the SDP sent, the<= br> > termination side could know that, but the basic identity mechanism
> could succeed anyway (that is, you knew you had a valid identity and a= modified SDP).
>
> Brian
>
> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote:
>
> =A0 =A0 Would it be possible to provide an indication of whether the c= alling
> =A0 =A0 name was validated (in the same sense that the calling number = was
> =A0 =A0 validated, but an independent indication)?____
>
> =A0 =A0 __ __
>
> =A0 =A0 ISTM that should be a simple exercise, protocol-wise. =A0And i= t
> =A0 =A0 maintains the parallel treatment of name and number that we ha= ve
> =A0 =A0 today (e.g., there are today separate indications of privacy, = for
> =A0 =A0 name and number). =A0But that's not my main concern; mostl= y I'm
> =A0 =A0 thinking of the evolution of the process by which calling name= is
> =A0 =A0 provided. =A0Even if it's not possible to validate calling= name as
> =A0 =A0 provided by CNAM, it might be possible to validate calling nam= e as
> =A0 =A0 provided by other methods; e.g., by the calling network in the=
> =A0 =A0 display-name header field in the FROM or (more likely in publi= c
> =A0 =A0 networks) the P-A-ID header.____
>
> =A0 =A0 __ __
>
> =A0 =A0 tim____
>
> =A0 =A0 __ __
>
> =A0 =A0 __ __
>
> =A0 =A0 *From:*stir-bounces@i= etf.org <javascript:_e({}, 'cvml',
> =A0 =A0 'stir-bounces@iet= f.org');> [mailto:stir-= bounces@ietf.org
> =A0 =A0 <javascript:_e({}, 'cvml', 'stir-bounces@ietf.org');>] *On Behalf Of > =A0 =A0 *PFAUTZ, PENN L
> =A0 =A0 *Sent:* Wednesday, August 14, 2013 9:37 AM
> =A0 =A0 *To:* Brian Rosen; Hadriel Kaplan
> =A0 =A0 *Cc:* stir@ietf.org <j= avascript:_e({}, 'cvml', 'stir= @ietf.org');>;
> =A0 =A0 Paul Kyzivat
> =A0 =A0 *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF = to
> =A0 =A0 Charter)____
>
> =A0 =A0 __ __
>
> =A0 =A0 I assume the concern in this thread is with the case where a n= umber
> =A0 =A0 might be authenticated but the CNAM displayed would be mislead= ing
> =A0 =A0 because of lax policies of the CNAM provider - e.g., the bad g= uy
> =A0 =A0 makes a call from what is indeed his legit number but has mana= ged to
> =A0 =A0 get Bank of America into his CNAM entry.____
>
> =A0 =A0 __ __
>
> =A0 =A0 I'm thinking that taking on CNAM in the ietf may be a brid= ge too far
> =A0 =A0 for stir. Leave what happens after the number is validated up = to
> =A0 =A0 national authorities since arrangements may differ. And at lea= st in
> =A0 =A0 the case above it should be possible to trace back to the
> perp.____
>
> =A0 =A0 __ __
>
> =A0 =A0 More generally I think the object of stir ought to be just to<= br> > =A0 =A0 provide the customer an indication of whether the calling numb= er was
> =A0 =A0 validated on not - whether calls get blocked or unvalidated nu= mbers
> =A0 =A0 are still displayed should be up to the customer and their ser= vice
> =A0 =A0 provider.____
>
> =A0 =A0 __ __
>
> =A0 =A0 Penn Pfautz____
>
> =A0 =A0 AT&T Access Management____
>
> =A0 =A0 +1-73= 2-420-4962____
>
> =A0 =A0 *From:*stir-bounces@i= etf.org [mailto:stir-bounces@i= etf.org] *On
> =A0 =A0 Behalf Of *Brian Rosen
> =A0 =A0 *Sent:* Wednesday, August 14, 2013 9:32 AM
> =A0 =A0 *To:* Hadriel Kaplan
> =A0 =A0 *Cc:* stir@ietf.org; Paul= Kyzivat
> =A0 =A0 *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF = to
> =A0 =A0 Charter)____
>
> =A0 =A0 __ __
>
> =A0 =A0 I think we probably should keep CNAM out of this for now
> anyway.____
>
> =A0 =A0 __ __
>
> =A0 =A0 The advantage of the credential delegation process as we have<= br> > =A0 =A0 defined it is that it's authoritative.____
>
> =A0 =A0 __ __
>
> =A0 =A0 The current CNAM databases cannot be called "authoritativ= e" really.
> =A0 =A0 =A0 Classically, as you describe, there is a database operated= by on
> =A0 =A0 on behalf of the origination carrier and queried by the termin= ation
> =A0 =A0 carrier (often with a charge to query). =A0The content is what= the
> =A0 =A0 carrier has recorde from the original service order, but there= isn't
> =A0 =A0 any attempt to validate those names, and there are carriers wh= o will
> =A0 =A0 let you put anything you like in there. =A0How "authorita= tive" is
> =A0 =A0 that? =A0Then there are other databases, like Neustar's, t= hat don't
> =A0 =A0 have any relationship to the originination carrier - the termi= nation
> =A0 =A0 carrier dips an independently developed database of name-numbe= r
> =A0 =A0 relationships. =A0These databases are developed using a wide v= ariety
> =A0 =A0 of sources and have evolved to be very accurate, but hardly > =A0 =A0 "authoritative".____
>
> =A0 =A0 __ __
>
> =A0 =A0 And yes, Hadriel, there are regulatory restrictions, mostly ab= out
> =A0 =A0 what the NPAC (number portability database administrator) can = do.
> =A0 =A0 The CNAM databases have very few regulations to deal with.____=
>
> =A0 =A0 __ __
>
> =A0 =A0 Brian ____
>
>
> =A0 =A0 On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____
>
>
> =A0 =A0 On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <pk
>

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir
_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--047d7b2e3e68feb70004e4031c45-- From timothy.dwight@verizon.com Thu Aug 15 15:41:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F3811E813B for ; Thu, 15 Aug 2013 15:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKgK3SjD5gU6 for ; Thu, 15 Aug 2013 15:41:31 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id B8A5411E80A2 for ; Thu, 15 Aug 2013 15:41:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 15 Aug 2013 22:41:28 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,889,1367971200"; d="scan'208,217";a="528622678" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 15 Aug 2013 22:41:28 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Thu, 15 Aug 2013 18:41:28 -0400 To: Brian Rosen , Henning Schulzrinne Date: Thu, 15 Aug 2013 18:41:25 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: Ac6Z/frib2daK1ZfRP6wWTAtZybgfQAA9oLg Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3B9A@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@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: multipart/alternative; boundary="_000_2B0F677F0B95454297753F58D4A07FA3012ADB3B9AFHDP1LUMXC7V3_" MIME-Version: 1.0 Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 22:41:40 -0000 --_000_2B0F677F0B95454297753F58D4A07FA3012ADB3B9AFHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, Please see responses inline, below. tim From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, August 15, 2013 4:25 PM To: Henning Schulzrinne Cc: Dwight, Timothy M (Tim); Paul Kyzivat; stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) With respect to caller ID, at least at present, the caller id that is usual= ly presented to the user comes from a database as a result of a query. The= SIP signaling protocol provides ways to carry the information, but the dat= a the user sees is generally the result of a CNAM dip. That dip is done on= the termination side. Now, that is certainly more true of legacy wireline/wireless than VoIP endp= oints, but lots of VoIP endpoints do in fact display the result of the CNAM= dip one way or another. [tmd] Agreed, this is the norm for Wireline VoIP. What you see on your mob= ile is usually the result of your phone looking up the calling party number= in your contact list. At least if there's a match, that's what you see. = If there's no match, calling name information (or city/state information, o= r calling party's company information) may be provided by your cell phone c= ompany. That capability is relatively recent, and certainly not universal.= A big driver for this was demand from Enterprises, who wanted something l= ike "Sears appliance repair service" displayed when their technician calls = a customer from his mobile. We can try to change that - we can try to change to using the data carried = in the call, set by the origination side and used by the termination side. [tmd] I think this is inevitable. The existing system is inefficient - the= calling network withholds information it could have included in the setup = request, forcing the terminating network to request it (and charging them f= or having done so). We already see evidence of a desire to change it, in V= oIP interconnect discussions with other carriers. As long as there is a charge by the origination network to get the CNAM dat= a levied on the termination network, obsoleting those databases may be hard= . The databases that use independently validated name-number associations = exist to avoid paying that charge. They also generally are more accurate b= ecause the opportunities for fraud are significantly reduced, but they are = not as comprehensive (generally, the CNAM directories have entries for each= and every TN served by a carrier. [tmd] The first sentence is certainly true. The rest is arguable. I am no= t aware of any data regarding the relative accuracy of CNAM databases, and = while it's true that the terminating network may avoid paying the originati= ng carrier if he instead queries some 3rd party, those 3rd party services a= ren't free. If we changed the way the data is delivered to the termination endpoint, th= en we would have to consider how to assure that it's valid, and not messed = with (MITM). The former is the difficulty we have. [tmd] Right. I'm trying to discuss whether it is or should be a requiremen= t, though. This is all good discussion, but we shouldn't just shrug things= off because they're hard. I don't want this effort to be just the latest = toothless non-solution to the problem our customers experience. So, are you thinking we could reasonably change the entire CNAM ecosystem? [tmd] It's being discussed. It sometimes comes up in VoIP interconnect dis= cussions, for example. If you think that is feasible, than we can talk about what mechanisms might= be appropriate. [tmd] I continue to find this a backwards discussion. Nobody seems to want= to talk about whether it's necessary in order to have a solution that meet= s the customers' needs. We only want to talk about whether it's hard, or w= hether the solution we've already got in mind would easily accommodate it. But anyway, to answer your question, Yes, I think change is feasible. Keep= in mind that the "growth areas" of telecommunications are generally not st= rongly vested in the status quo. Brian On Thu, Aug 15, 2013 at 5:06 PM, Henning Schulzrinne > wrote: I fully agree that trustworthy information about the caller (identity, pref= erably beyond what fits into 15 characters) is a worthy goal, but tradition= al caller ID may just be too limited for that purpose. The problem is that I don't see a good way to do this by signing. There are= three cases I can see: * #1: Bad (spoofed) number, spoofed text --> STIR will flag that and presum= ably lead recipients to ignore or question both; * #2: Good (signed) number, spoofed text: this should only occur if there's= a MITM attack where somebody replaces (say) the personal name with a misle= ading one ("John Doe" becomes "Bank of America") * #3: Dodgy or careless provider: the number is legitimately assigned and s= igned, but the provider allows the caller to insert any textual information= they want, either on-a-call-by-call basis or when signing up for service i= nitially. As noted by others, signing doesn't help here, but you can at lea= st identify the perpetrator and there is private recourse, such as trademar= k violations, that are not available for number spoofing. Given that we've largely declared MITM and call hijacking to be out of (ini= tial) STIR scope and that this attack vector seems somewhat unlikely in pra= ctice, that leaves case #3. I do see one potential hijack attack that we might want to and can prevent,= namely the copy-paste attack, where somebody has access to legitimate inbo= und calls, signed, and then re-issues the call with a spoofed textual infor= mation, assuming they don't care about the originating number (which would = be the case for phishing attacks). That requires very little effort for the= SIP case, and might argue for cryptographically including the text in a si= gnature, which simply asserts that the same entity that signed the number a= lso saw the same text, whatever its legal validity might be. If end users a= re allowed to sign, this doesn't help much, since they can just use case #3= . For traditional CA-issue web certs (not the EV variety), you can pretty muc= h put anything in the organization name and the location, and you'll get is= sued a cert that includes that information. The only proof is that the hold= er has operative control of the domain name that's in the cert. This does not apply to the CNAM case, just the inband display name case; CN= AM seems similar to the "dodgy/careless" case above. Henning -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Thursday, August 15, 2013 3:39 PM To: Henning Schulzrinne; 'Paul Kyzivat'; Brian Rosen Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) With respect, I think statements like " I don't see how signing helps " put= the cart before the horse. Signing is an attribute of a possible solution= , not a requirement. It is precisely the www.callerid4u.com scenario = you note, that worries me. ISTM that if we declare any sort of validation = for calling name to be out of scope, we provide no solution to the victims = of scams enabled by services that allow dishonest actors to associate the n= ame of a bank with their phone number. I recognize that names are not delegated in the same way that numbers are, = and that there are all sorts of semantic nuances that make their validation= difficult. Still, CA's do it. And it's been proposed on this list that a= smartphone app could do it. So I don't see why we're so quick to agree we= can't do it. Or at least, do something. I'm a pragmatist. Maybe we can't do as good a job validating names as we c= an numbers. I still think it's better to make things better than to do not= hing. For example ISTM it'd be positive progress to enable the called part= y to make a more informed decision about whether to trust the calling name,= than he can today. tim p.s. I tend to agree with Rich, that we can't forever duck the issue of wha= t gets presented to the called party. Whether it's addressed directly or n= ot, we're already making assumptions about what is and isn't reasonable. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinn= e Sent: Wednesday, August 14, 2013 2:19 PM To: 'Paul Kyzivat'; Brian Rosen Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Just piling on... There are at least three levels of information here, maki= ng it difficult to do that within the signaling framework: * the name of the person calling (vs. the subscriber name) * the name of the organization * properties of the organization ("licensed plumber", "FDIC-insured bank", = "located in Washington, DC", "registered charity") This is more whois-like information than just the SIP display name. In the = certificate space, we have two levels: (1) assertion of domain name control= ; (2) EV (extended validation) certs. It would be interesting to see how we= ll the EV concept has worked out in practice. I don't see how signing helps here at all, for the reasons mentioned. Nefar= ious actors can use services such as http://www.callerid4u.com/ to use a le= gitimate number with just about any name string. And for corporate accounts= , the service provider has no way of knowing whether Tom Sawyer is really a= t a particular number in a range and whether that entity prefers to list th= e name of the person, just the organization, the location ("PizzaHut Leonia= ") or something else. Indeed, the same number can legitimately have multipl= e display names that change quickly over time (e.g., staff at the doctor's = office). Verifiable whois-like information could be very useful and service provider= s could see that as an opportunity, given that they do know a lot about the= ir customers, such as their billing and service address and how long they h= ave been in business. But it's a separate problem, probably more closely re= lated to the number allocation problem. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, August 14, 2013 3:04 PM To: Brian Rosen Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M = (Tim); PFAUTZ, PENN L Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On 8/14/13 8:38 PM, Brian Rosen wrote: > I suppose it's possible, but what is the criteria for validation? > > With TNs, we have credentials that accompany number delegation - we > have a clear path to assuring that the caller asserting the identity > is indeed entitled to claim control of that number (well, SPs mostly, > not the caller, at least initially). There is no equivalent assurance > for CNAM. > > I don't want to get into a fight over which database is better, but > the alternate, doesn't depend on the origination carrier mechansism is > statisically actually a better "validation" of the content than what a > traditional carrier gets in his service order (because they usually > don't actually validate the content), and is infiniately better than > the carriers that allow the consumer to put anything they want in the > database. Without a reasonable way to assure that the database is > actually valid, what is the value of carrying an assertion? While I recognize that letting the customer put in whatever they want is pr= oblematic, I have no idea whether the alternative of letting the CNAM provi= der include whatever they want is "better". (How would we measure that?) (I've just been trying to deal with an "information aggregator" that is pub= lishing wrong information about me and won't change it. So I'm not feeling = good about that sort of thing.) ISTM that is is yet another example of ancient, informal, manual systems, t= hat once mostly "worked" based on the good will of the people involved, but= that have now been automated into monstrosities that nobody understands. (= Management of healthcare data is another example.) Ultimately there will need to be a big effort to develop a formal framework= for this. And it will probably require the creation of new laws. Alternatively this could be left to the open market. (E.g., The callee coul= d just Google the calling number.) In any case STIR can't go down this rat hole. Thanks, Paul > If we had such a mechanism, what prevents one of the carriers that > let's you put anything you want in the database from asserting that > the content of P-A-ID is valid, when the user is allowed to say > whatever they want goes in P-A-ID? > > The best thing I can come up with would be to have some independent > validation service that used other data sources to validate the > content, and let them sign it. Then we could carry that signature somewh= ere. > > Right now, I think we should leave it out of scope. If we can figure > out a way to do validation, then we can revisit the notion of carrying > evidence of validation in future work. > > Does argue for making sure that whatever mechanism we arrive at should > have some obvious extension mechanism, perhaps along the lines of what > Jon was suggesting for media properties. If you recall, he proposed > to have a digest of SDP where the digest was protected by the > signature, but if the SDP received didn't match the SDP sent, the > termination side could know that, but the basic identity mechanism > could succeed anyway (that is, you knew you had a valid identity and a mo= dified SDP). > > Brian > > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > > Would it be possible to provide an indication of whether the calling > name was validated (in the same sense that the calling number was > validated, but an independent indication)?____ > > __ __ > > ISTM that should be a simple exercise, protocol-wise. And it > maintains the parallel treatment of name and number that we have > today (e.g., there are today separate indications of privacy, for > name and number). But that's not my main concern; mostly I'm > thinking of the evolution of the process by which calling name is > provided. Even if it's not possible to validate calling name as > provided by CNAM, it might be possible to validate calling name as > provided by other methods; e.g., by the calling network in the > display-name header field in the FROM or (more likely in public > networks) the P-A-ID header.____ > > __ __ > > tim____ > > __ __ > > __ __ > > *From:*stir-bounces@ietf.org 'stir-bounces@ietf.org');> [mailto:stir= -bounces@ietf.org > ');>] *On Behalf Of > *PFAUTZ, PENN L > *Sent:* Wednesday, August 14, 2013 9:37 AM > *To:* Brian Rosen; Hadriel Kaplan > *Cc:* stir@ietf.org ; > Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I assume the concern in this thread is with the case where a number > might be authenticated but the CNAM displayed would be misleading > because of lax policies of the CNAM provider - e.g., the bad guy > makes a call from what is indeed his legit number but has managed to > get Bank of America into his CNAM entry.____ > > __ __ > > I'm thinking that taking on CNAM in the ietf may be a bridge too far > for stir. Leave what happens after the number is validated up to > national authorities since arrangements may differ. And at least in > the case above it should be possible to trace back to the > perp.____ > > __ __ > > More generally I think the object of stir ought to be just to > provide the customer an indication of whether the calling number was > validated on not - whether calls get blocked or unvalidated numbers > are still displayed should be up to the customer and their service > provider.____ > > __ __ > > Penn Pfautz____ > > AT&T Access Management____ > > +1-732-420-4962____ > > *From:*stir-bounces@ietf.org [mailto:st= ir-bounces@ietf.org] *On > Behalf Of *Brian Rosen > *Sent:* Wednesday, August 14, 2013 9:32 AM > *To:* Hadriel Kaplan > *Cc:* stir@ietf.org; Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I think we probably should keep CNAM out of this for now > anyway.____ > > __ __ > > The advantage of the credential delegation process as we have > defined it is that it's authoritative.____ > > __ __ > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on > on behalf of the origination carrier and queried by the termination > carrier (often with a charge to query). The content is what the > carrier has recorde from the original service order, but there isn't > any attempt to validate those names, and there are carriers who will > let you put anything you like in there. How "authoritative" is > that? Then there are other databases, like Neustar's, that don't > have any relationship to the originination carrier - the termination > carrier dips an independently developed database of name-number > relationships. These databases are developed using a wide variety > of sources and have evolved to be very accurate, but hardly > "authoritative".____ > > __ __ > > And yes, Hadriel, there are regulatory restrictions, mostly about > what the NPAC (number portability database administrator) can do. > The CNAM databases have very few regulations to deal with.____ > > __ __ > > Brian ____ > > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_2B0F677F0B95454297753F58D4A07FA3012ADB3B9AFHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,

 

Please see responses = inline, below.

 

=

tim

 

=

From: Brian Rosen [mailto:br@brianrosen.net]
Sent= : Thursday, August 15, 2013 4:25 PM
To: Henning SchulzrinneCc: Dwight, Timothy M (Tim); Paul Kyzivat; stir@ietf.org
Sub= ject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

 

With respect to caller ID, at least at present, the caller id = that is usually presented to the user comes from a database as a result of = a query.  The SIP signaling protocol provides ways to carry the inform= ation, but the data the user sees is generally the result of a CNAM dip. &n= bsp;That dip is done on the termination side.

 

Now, that= is certainly more true of legacy wireline/wireless than VoIP endpoints, bu= t lots of VoIP endpoints do in fact display the result of the CNAM dip one = way or another.

[tmd] Agreed, this is the no= rm for Wireline VoIP.  What you see on your mobile is usually the resu= lt of your phone looking up the calling party number in your contact list. =  At least if there’s a match, that’s what you see.  I= f there’s no match, calling name information (or city/state informati= on, or calling party’s company information) may be provided by your c= ell phone company.  That capability is relatively recent, and certainl= y not universal.  A big driver for this was demand from Enterprises, w= ho wanted something like “Sears appliance repair service” displ= ayed when their technician calls a customer from his mobile.=

 

We can try to change that - we can try to change to u= sing the data carried in the call, set by the origination side and used by = the termination side.

[tmd] I think this is= inevitable.  The existing system is inefficient – the calling n= etwork withholds information it could have included in the setup request, f= orcing the terminating network to request it (and charging them for having = done so).  We already see evidence of a desire to change it, in VoIP i= nterconnect discussions with other carriers.  <= /p>

 

As long as there is a charge by the origination network to get= the CNAM data levied on the termination network, obsoleting those database= s may be hard.  The databases that use independently validated name-nu= mber associations exist to avoid paying that charge.  They also genera= lly are more accurate because the opportunities for fraud are significantly= reduced, but they are not as comprehensive (generally, the CNAM directorie= s have entries for each and every TN served by a carrier.

[tmd] The first sentence is certainly true.  The rest is= arguable.  I am not aware of any data regarding the relative accuracy= of CNAM databases, and while it’s true that the terminating network = may avoid paying the originating carrier if he instead queries some 3r= d party, those 3rd party services aren’t free. =

 

If we changed the way the data is del= ivered to the termination endpoint, then we would have to consider how to a= ssure that it's valid, and not messed with (MITM).  The former is the = difficulty we have.

[tmd] Right.  IR= 17;m trying to discuss whether it is or should be a requirement, though.&nb= sp; This is all good discussion, but we shouldn’t just shrug things o= ff because they’re hard.  I don’t want this effort to be j= ust the latest toothless non-solution to the problem our customers experien= ce.

 

So, are you thinking we could reaso= nably change the entire CNAM ecosystem?

= [tmd= ] It’s being discussed.  It sometimes comes up in VoIP interconn= ect discussions, for example.

 

If you= think that is feasible, than we can talk about what mechanisms might be ap= propriate.

[tmd] I continue to find this a b= ackwards discussion.  Nobody seems to want to talk about whether it= 217;s necessary in order to have a solution that meets the customers’= needs.  We only want to talk about whether it’s hard, or whethe= r the solution we’ve already got in mind would easily accommodate it.=

 =

But anyway, to answer your question, Yes, I think = change is feasible.  Keep in mind that the “growth areas” = of telecommunications are generally not strongly vested in the status quo.<= /span>

 =

Brian

 

On Thu, Aug 15, 2013 at 5:06 PM, Henning Schulzrinne = <Hennin= g.Schulzrinne@fcc.gov> wrote:

I f= ully agree that trustworthy information about the caller (identity, prefera= bly beyond what fits into 15 characters) is a worthy goal, but traditional = caller ID may just be too limited for that purpose.

The problem is t= hat I don't see a good way to do this by signing. There are three cases I c= an see:

* #1: Bad (spoofed) number, spoofed text --> STIR will fl= ag that and presumably lead recipients to ignore or question both;

*= #2: Good (signed) number, spoofed text: this should only occur if there's = a MITM attack where somebody replaces (say) the personal name with a mislea= ding one ("John Doe" becomes "Bank of America")

= * #3: Dodgy or careless provider: the number is legitimately assigned and s= igned, but the provider allows the caller to insert any textual information= they want, either on-a-call-by-call basis or when signing up for service i= nitially. As noted by others, signing doesn't help here, but you can at lea= st identify the perpetrator and there is private recourse, such as trademar= k violations, that are not available for number spoofing.

Given that= we've largely declared MITM and call hijacking to be out of (initial) STIR= scope and that this attack vector seems somewhat unlikely in practice, tha= t leaves case #3.

I do see one potential hijack attack that we might= want to and can prevent, namely the copy-paste attack, where somebody has = access to legitimate inbound calls, signed, and then re-issues the call wit= h a spoofed textual information, assuming they don't care about the origina= ting number (which would be the case for phishing attacks). That requires v= ery little effort for the SIP case, and might argue for cryptographically i= ncluding the text in a signature, which simply asserts that the same entity= that signed the number also saw the same text, whatever its legal validity= might be. If end users are allowed to sign, this doesn't help much, since = they can just use case #3.

For traditional CA-issue web certs (not t= he EV variety), you can pretty much put anything in the organization name a= nd the location, and you'll get issued a cert that includes that informatio= n. The only proof is that the holder has operative control of the domain na= me that's in the cert.

This does not apply to the CNAM case, just th= e inband display name case; CNAM seems similar to the "dodgy/careless&= quot; case above.

Henning


-----Ori= ginal Message-----
From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Thu= rsday, August 15, 2013 3:39 PM
To: Henning Schulzrinne; 'Paul Kyzivat'; = Brian Rosen
Cc: stir@ietf.org<= /o:p>

Subject: RE: [stir] Early Hom= ework (was Re: Moving from BOF to Charter)

With respect, I think sta= tements like " I don't see how signing helps " put the cart befor= e the horse.  Signing is an attribute of a possible solution, not a re= quirement.

It is precisely the www.callerid4u.com scenario you note, that worries m= e.  ISTM that if we declare any sort of validation for calling name to= be out of scope, we provide no solution to the victims of scams enabled by= services that allow dishonest actors to associate the name of a bank with = their phone number.

I recognize that names are not delegated in the = same way that numbers are, and that there are all sorts of semantic nuances= that make their validation difficult.  Still, CA's do it.  And i= t's been proposed on this list that a smartphone app could do it.  So = I don't see why we're so quick to agree we can't do it.  Or at least, = do something.

I'm a pragmatist.  Maybe we can't do as good a jo= b validating names as we can numbers.  I still think it's better to ma= ke things better than to do nothing.  For example ISTM it'd be positiv= e progress to enable the called party to make a more informed decision abou= t whether to trust the calling name, than he can today.

tim

p= .s. I tend to agree with Rich, that we can't forever duck the issue of what= gets presented to the called party.  Whether it's addressed directly = or not, we're already making assumptions about what is and isn't reasonable= .


-----Original Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne<= br>Sent: Wednesday, August 14, 2013 2:19 PM
To: 'Paul Kyzivat'; Brian Ro= sen
Cc: stir@ietf.org
Subject: R= e: [stir] Early Homework (was Re: Moving from BOF to Charter)

Just p= iling on... There are at least three levels of information here, making it = difficult to do that within the signaling framework:

* the name of t= he person calling (vs. the subscriber name)
* the name of the organizati= on
* properties of the organization ("licensed plumber", "= ;FDIC-insured bank", "located in Washington, DC", "regi= stered charity")

This is more whois-like information than just = the SIP display name. In the certificate space, we have two levels: (1) ass= ertion of domain name control; (2) EV (extended validation) certs. It would= be interesting to see how well the EV concept has worked out in practice.<= br>
I don't see how signing helps here at all, for the reasons mentioned= . Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimat= e number with just about any name string. And for corporate accounts, the s= ervice provider has no way of knowing whether Tom Sawyer is really at a par= ticular number in a range and whether that entity prefers to list the name = of the person, just the organization, the location ("PizzaHut Leonia&q= uot;) or something else. Indeed, the same number can legitimately have mult= iple display names that change quickly over time (e.g., staff at the doctor= 's office).

Verifiable whois-like information could be very useful a= nd service providers could see that as an opportunity, given that they do k= now a lot about their customers, such as their billing and service address = and how long they have been in business. But it's a separate problem, proba= bly more closely related to the number allocation problem.

-----Orig= inal Message-----
From: stir-bo= unces@ietf.org [mailto:stir-bo= unces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Wednesday, August 14= , 2013 3:04 PM
To: Brian Rosen
Cc: s= tir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN LSubject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)
On 8/14/13 8:38 PM, Brian Rosen wrote:
> I suppose it's possibl= e, but what is the criteria for validation?
>
> With TNs, we ha= ve credentials that accompany number delegation - we
> have a clear p= ath to assuring that the caller asserting the identity
> is indeed en= titled to claim control of that number (well, SPs mostly,
> not the c= aller, at least initially).  There is no equivalent assurance
> = for CNAM.
>
> I don't want to get into a fight over which datab= ase is better, but
> the alternate, doesn't depend on the origination= carrier mechansism is
> statisically actually a better "validat= ion" of the content than what a
> traditional carrier gets in hi= s service order (because they usually
> don't actually validate the c= ontent), and is infiniately better than
> the carriers that allow the= consumer to put anything they want in the
> database.  Without = a reasonable way to assure that the database is
> actually valid, wha= t is the value of carrying an assertion?

While I recognize that lett= ing the customer put in whatever they want is problematic, I have no idea w= hether the alternative of letting the CNAM provider include whatever they w= ant is "better". (How would we measure
that?)

(I've jus= t been trying to deal with an "information aggregator" that is pu= blishing wrong information about me and won't change it. So I'm not feeling= good about that sort of thing.)

ISTM that is is yet another example= of ancient, informal, manual systems, that once mostly "worked" = based on the good will of the people involved, but that have now been autom= ated into monstrosities that nobody understands. (Management of healthcare = data is another example.)

Ultimately there will need to be a big eff= ort to develop a formal framework for this. And it will probably require th= e creation of new laws.

Alternatively this could be left to the open= market. (E.g., The callee could just Google the calling number.)

In= any case STIR can't go down this rat hole.

      &nb= sp; Thanks,
        Paul

> If we had such = a mechanism, what prevents one of the carriers that
> let's you put a= nything you want in the database from asserting that
> the content of= P-A-ID is valid, when the user is allowed to say
> whatever they wan= t goes in P-A-ID?
>
> The best thing I can come up with would b= e to have some independent
> validation service that used other data = sources to validate the
> content, and let them sign it.  Then w= e could carry that signature somewhere.
>
> Right now, I think = we should leave it out of scope.  If we can figure
> out a way t= o do validation, then we can revisit the notion of carrying
> evidenc= e of validation in future work.
>
> Does argue for making sure = that whatever mechanism we arrive at should
> have some obvious exten= sion mechanism, perhaps along the lines of what
> Jon was suggesting = for media properties.  If you recall, he proposed
> to have a di= gest of SDP where the digest was protected by the
> signature, but if= the SDP received didn't match the SDP sent, the
> termination side c= ould know that, but the basic identity mechanism
> could succeed anyw= ay (that is, you knew you had a valid identity and a modified SDP).
>=
> Brian
>
> On Wednesday, August 14, 2013, Dwight, Timot= hy M (Tim) wrote:
>
>     Would it be possible to pro= vide an indication of whether the calling
>     name was va= lidated (in the same sense that the calling number was
>    = ; validated, but an independent indication)?____
>
>   &nb= sp; __ __
>
>     ISTM that should be a simple exerci= se, protocol-wise.  And it
>     maintains the paralle= l treatment of name and number that we have
>     today (e.= g., there are today separate indications of privacy, for
>   &nb= sp; name and number).  But that's not my main concern; mostly I'm
&= gt;     thinking of the evolution of the process by which calling= name is
>     provided.  Even if it's not possible to= validate calling name as
>     provided by CNAM, it might = be possible to validate calling name as
>     provided by o= ther methods; e.g., by the calling network in the
>     dis= play-name header field in the FROM or (more likely in public
>  =   networks) the P-A-ID header.____
>
>     __ _= _
>
>     tim____
>
>     __ __=
>
>     __ __
>
>     *From:*<= a href=3D"mailto:stir-bounces@ietf.org">stir-bounces@ietf.org <javas= cript:_e({}, 'cvml',
>     'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org
>     <javasc= ript:_e({}, 'cvml', 'stir-bounces@= ietf.org');>] *On Behalf Of
>     *PFAUTZ, PENN L>     *Sent:* Wednesday, August 14, 2013 9:37 AM
> &nbs= p;   *To:* Brian Rosen; Hadriel Kaplan
>     *Cc:* stir@ietf.org <javascript:_e({}, 'cvml= ', 'stir@ietf.org');>;
> &nbs= p;   Paul Kyzivat
>     *Subject:* Re: [stir] Early Ho= mework (was Re: Moving from BOF to
>     Charter)____
&g= t;
>     __ __
>
>     I assume the c= oncern in this thread is with the case where a number
>    = might be authenticated but the CNAM displayed would be misleading
> =     because of lax policies of the CNAM provider - e.g., the bad = guy
>     makes a call from what is indeed his legit number= but has managed to
>     get Bank of America into his CNAM= entry.____
>
>     __ __
>
>   &nbs= p; I'm thinking that taking on CNAM in the ietf may be a bridge too far
= >     for stir. Leave what happens after the number is validat= ed up to
>     national authorities since arrangements may = differ. And at least in
>     the case above it should be p= ossible to trace back to the
> perp.____
>
>    = ; __ __
>
>     More generally I think the object of = stir ought to be just to
>     provide the customer an indi= cation of whether the calling number was
>     validated on= not - whether calls get blocked or unvalidated numbers
>   &nbs= p; are still displayed should be up to the customer and their service
&g= t;     provider.____
>
>     __ __
><= br>>     Penn Pfautz____
>
>     AT&= T Access Management____
>
>     +1-732-420-4962____
>
>     *From:*<= a href=3D"mailto:stir-bounces@ietf.org">stir-bounces@ietf.org [mailto:<= a href=3D"mailto:stir-bounces@ietf.org">stir-bounces@ietf.org] *On
&= gt;     Behalf Of *Brian Rosen
>     *Sent:* Wedn= esday, August 14, 2013 9:32 AM
>     *To:* Hadriel Kaplan>     *Cc:* stir@ietf.org; Paul Kyzivat
>     *Subject:* Re: [stir] Early Homework= (was Re: Moving from BOF to
>     Charter)____
>
= >     __ __
>
>     I think we probably = should keep CNAM out of this for now
> anyway.____
>
> &n= bsp;   __ __
>
>     The advantage of the creden= tial delegation process as we have
>     defined it is that= it's authoritative.____
>
>     __ __
>
>= ;     The current CNAM databases cannot be called "authorita= tive" really.
>       Classically, as you describ= e, there is a database operated by on
>     on behalf of th= e origination carrier and queried by the termination
>     = carrier (often with a charge to query).  The content is what the
&g= t;     carrier has recorde from the original service order, but t= here isn't
>     any attempt to validate those names, and t= here are carriers who will
>     let you put anything you l= ike in there.  How "authoritative" is
>     = that?  Then there are other databases, like Neustar's, that don't
&= gt;     have any relationship to the originination carrier - the = termination
>     carrier dips an independently developed d= atabase of name-number
>     relationships.  These dat= abases are developed using a wide variety
>     of sources = and have evolved to be very accurate, but hardly
>     &quo= t;authoritative".____
>
>     __ __
>
&= gt;     And yes, Hadriel, there are regulatory restrictions, most= ly about
>     what the NPAC (number portability database a= dministrator) can do.
>     The CNAM databases have very fe= w regulations to deal with.____
>
>     __ __
>=
>     Brian ____
>
>
>     On = Wednesday, August 14, 2013, Hadriel Kaplan wrote:____
>
>
&g= t;     On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <pk
><= br>
_______________________________________________
stir mailing list=
stir@ietf.org
https://www.ietf.or= g/mailman/listinfo/stir
____________________________________________= ___
stir mailing list
stir@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/stir

 

= --_000_2B0F677F0B95454297753F58D4A07FA3012ADB3B9AFHDP1LUMXC7V3_-- From timothy.dwight@verizon.com Thu Aug 15 16:03:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D1B11E8213 for ; Thu, 15 Aug 2013 16:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FRT_PENIS1=3.592, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRJB6EmAqMAr for ; Thu, 15 Aug 2013 16:03:14 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1160F11E8214 for ; Thu, 15 Aug 2013 16:03:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 15 Aug 2013 23:03:07 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,889,1367971200"; d="scan'208";a="528631301" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 15 Aug 2013 23:03:07 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Thu, 15 Aug 2013 19:03:07 -0400 To: Henning Schulzrinne , 'Paul Kyzivat' , Brian Rosen Date: Thu, 15 Aug 2013 19:03:03 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbCAAZhJ4IAAFt9AgAAkEuA= Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3BAC@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@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 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 23:03:19 -0000 Henning, I agree with what you say but I'm not sure what to conclude from it. You s= eem to be saying you agree that case #3 needs to be resolved, but it's hard= . So, is it eliminated as a requirement because it's hard? Does a solutio= n that fails to address this, meet the public's need or the FCC mandate? tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, August 15, 2013 4:07 PM To: Dwight, Timothy M (Tim); 'Paul Kyzivat'; Brian Rosen Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) I fully agree that trustworthy information about the caller (identity, pref= erably beyond what fits into 15 characters) is a worthy goal, but tradition= al caller ID may just be too limited for that purpose. The problem is that I don't see a good way to do this by signing. There are= three cases I can see: * #1: Bad (spoofed) number, spoofed text --> STIR will flag that and presum= ably lead recipients to ignore or question both; * #2: Good (signed) number, spoofed text: this should only occur if there's= a MITM attack where somebody replaces (say) the personal name with a misle= ading one ("John Doe" becomes "Bank of America") * #3: Dodgy or careless provider: the number is legitimately assigned and s= igned, but the provider allows the caller to insert any textual information= they want, either on-a-call-by-call basis or when signing up for service i= nitially. As noted by others, signing doesn't help here, but you can at lea= st identify the perpetrator and there is private recourse, such as trademar= k violations, that are not available for number spoofing. Given that we've largely declared MITM and call hijacking to be out of (ini= tial) STIR scope and that this attack vector seems somewhat unlikely in pra= ctice, that leaves case #3. I do see one potential hijack attack that we might want to and can prevent,= namely the copy-paste attack, where somebody has access to legitimate inbo= und calls, signed, and then re-issues the call with a spoofed textual infor= mation, assuming they don't care about the originating number (which would = be the case for phishing attacks). That requires very little effort for the= SIP case, and might argue for cryptographically including the text in a si= gnature, which simply asserts that the same entity that signed the number a= lso saw the same text, whatever its legal validity might be. If end users a= re allowed to sign, this doesn't help much, since they can just use case #3= . For traditional CA-issue web certs (not the EV variety), you can pretty muc= h put anything in the organization name and the location, and you'll get is= sued a cert that includes that information. The only proof is that the hold= er has operative control of the domain name that's in the cert. This does not apply to the CNAM case, just the inband display name case; CN= AM seems similar to the "dodgy/careless" case above. Henning -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Thursday, August 15, 2013 3:39 PM To: Henning Schulzrinne; 'Paul Kyzivat'; Brian Rosen Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) With respect, I think statements like " I don't see how signing helps " put= the cart before the horse. Signing is an attribute of a possible solution= , not a requirement. It is precisely the www.callerid4u.com scenario you note, that worries me. = ISTM that if we declare any sort of validation for calling name to be out = of scope, we provide no solution to the victims of scams enabled by service= s that allow dishonest actors to associate the name of a bank with their ph= one number. I recognize that names are not delegated in the same way that numbers are, = and that there are all sorts of semantic nuances that make their validation= difficult. Still, CA's do it. And it's been proposed on this list that a= smartphone app could do it. So I don't see why we're so quick to agree we= can't do it. Or at least, do something. I'm a pragmatist. Maybe we can't do as good a job validating names as we c= an numbers. I still think it's better to make things better than to do not= hing. For example ISTM it'd be positive progress to enable the called part= y to make a more informed decision about whether to trust the calling name,= than he can today. tim p.s. I tend to agree with Rich, that we can't forever duck the issue of wha= t gets presented to the called party. Whether it's addressed directly or n= ot, we're already making assumptions about what is and isn't reasonable. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Wednesday, August 14, 2013 2:19 PM To: 'Paul Kyzivat'; Brian Rosen Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Just piling on... There are at least three levels of information here, maki= ng it difficult to do that within the signaling framework: * the name of the person calling (vs. the subscriber name) * the name of the organization * properties of the organization ("licensed plumber", "FDIC-insured bank", = "located in Washington, DC", "registered charity") This is more whois-like information than just the SIP display name. In the = certificate space, we have two levels: (1) assertion of domain name control= ; (2) EV (extended validation) certs. It would be interesting to see how we= ll the EV concept has worked out in practice. I don't see how signing helps here at all, for the reasons mentioned. Nefar= ious actors can use services such as http://www.callerid4u.com/ to use a le= gitimate number with just about any name string. And for corporate accounts= , the service provider has no way of knowing whether Tom Sawyer is really a= t a particular number in a range and whether that entity prefers to list th= e name of the person, just the organization, the location ("PizzaHut Leonia= ") or something else. Indeed, the same number can legitimately have multipl= e display names that change quickly over time (e.g., staff at the doctor's = office). Verifiable whois-like information could be very useful and service provider= s could see that as an opportunity, given that they do know a lot about the= ir customers, such as their billing and service address and how long they h= ave been in business. But it's a separate problem, probably more closely re= lated to the number allocation problem. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Wednesday, August 14, 2013 3:04 PM To: Brian Rosen Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On 8/14/13 8:38 PM, Brian Rosen wrote: > I suppose it's possible, but what is the criteria for validation? > > With TNs, we have credentials that accompany number delegation - we > have a clear path to assuring that the caller asserting the identity > is indeed entitled to claim control of that number (well, SPs mostly, > not the caller, at least initially). There is no equivalent assurance > for CNAM. > > I don't want to get into a fight over which database is better, but > the alternate, doesn't depend on the origination carrier mechansism is > statisically actually a better "validation" of the content than what a > traditional carrier gets in his service order (because they usually > don't actually validate the content), and is infiniately better than > the carriers that allow the consumer to put anything they want in the > database. Without a reasonable way to assure that the database is > actually valid, what is the value of carrying an assertion? While I recognize that letting the customer put in whatever they want is pr= oblematic, I have no idea whether the alternative of letting the CNAM provi= der include whatever they want is "better". (How would we measure that?) (I've just been trying to deal with an "information aggregator" that is pub= lishing wrong information about me and won't change it. So I'm not feeling = good about that sort of thing.) ISTM that is is yet another example of ancient, informal, manual systems, t= hat once mostly "worked" based on the good will of the people involved, but= that have now been automated into monstrosities that nobody understands. (= Management of healthcare data is another example.) Ultimately there will need to be a big effort to develop a formal framework= for this. And it will probably require the creation of new laws. Alternatively this could be left to the open market. (E.g., The callee coul= d just Google the calling number.) In any case STIR can't go down this rat hole. Thanks, Paul > If we had such a mechanism, what prevents one of the carriers that > let's you put anything you want in the database from asserting that > the content of P-A-ID is valid, when the user is allowed to say > whatever they want goes in P-A-ID? > > The best thing I can come up with would be to have some independent > validation service that used other data sources to validate the > content, and let them sign it. Then we could carry that signature somewh= ere. > > Right now, I think we should leave it out of scope. If we can figure > out a way to do validation, then we can revisit the notion of carrying > evidence of validation in future work. > > Does argue for making sure that whatever mechanism we arrive at should > have some obvious extension mechanism, perhaps along the lines of what > Jon was suggesting for media properties. If you recall, he proposed > to have a digest of SDP where the digest was protected by the > signature, but if the SDP received didn't match the SDP sent, the > termination side could know that, but the basic identity mechanism > could succeed anyway (that is, you knew you had a valid identity and a mo= dified SDP). > > Brian > > On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > > Would it be possible to provide an indication of whether the calling > name was validated (in the same sense that the calling number was > validated, but an independent indication)?____ > > __ __ > > ISTM that should be a simple exercise, protocol-wise. And it > maintains the parallel treatment of name and number that we have > today (e.g., there are today separate indications of privacy, for > name and number). But that's not my main concern; mostly I'm > thinking of the evolution of the process by which calling name is > provided. Even if it's not possible to validate calling name as > provided by CNAM, it might be possible to validate calling name as > provided by other methods; e.g., by the calling network in the > display-name header field in the FROM or (more likely in public > networks) the P-A-ID header.____ > > __ __ > > tim____ > > __ __ > > __ __ > > *From:*stir-bounces@ietf.org 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org > ] *On Behalf Of > *PFAUTZ, PENN L > *Sent:* Wednesday, August 14, 2013 9:37 AM > *To:* Brian Rosen; Hadriel Kaplan > *Cc:* stir@ietf.org ; > Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I assume the concern in this thread is with the case where a number > might be authenticated but the CNAM displayed would be misleading > because of lax policies of the CNAM provider - e.g., the bad guy > makes a call from what is indeed his legit number but has managed to > get Bank of America into his CNAM entry.____ > > __ __ > > I'm thinking that taking on CNAM in the ietf may be a bridge too far > for stir. Leave what happens after the number is validated up to > national authorities since arrangements may differ. And at least in > the case above it should be possible to trace back to the > perp.____ > > __ __ > > More generally I think the object of stir ought to be just to > provide the customer an indication of whether the calling number was > validated on not - whether calls get blocked or unvalidated numbers > are still displayed should be up to the customer and their service > provider.____ > > __ __ > > Penn Pfautz____ > > AT&T Access Management____ > > +1-732-420-4962____ > > *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On > Behalf Of *Brian Rosen > *Sent:* Wednesday, August 14, 2013 9:32 AM > *To:* Hadriel Kaplan > *Cc:* stir@ietf.org; Paul Kyzivat > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > Charter)____ > > __ __ > > I think we probably should keep CNAM out of this for now > anyway.____ > > __ __ > > The advantage of the credential delegation process as we have > defined it is that it's authoritative.____ > > __ __ > > The current CNAM databases cannot be called "authoritative" really. > Classically, as you describe, there is a database operated by on > on behalf of the origination carrier and queried by the termination > carrier (often with a charge to query). The content is what the > carrier has recorde from the original service order, but there isn't > any attempt to validate those names, and there are carriers who will > let you put anything you like in there. How "authoritative" is > that? Then there are other databases, like Neustar's, that don't > have any relationship to the originination carrier - the termination > carrier dips an independently developed database of name-number > relationships. These databases are developed using a wide variety > of sources and have evolved to be very accurate, but hardly > "authoritative".____ > > __ __ > > And yes, Hadriel, there are regulatory restrictions, mostly about > what the NPAC (number portability database administrator) can do. > The CNAM databases have very few regulations to deal with.____ > > __ __ > > Brian ____ > > > On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ > > > On Aug 13, 2013, at 10:20 PM, Paul Kyzivat _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Thu Aug 15 19:15:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A0F21F9FCF for ; Thu, 15 Aug 2013 19:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlwqlQ0xxI9A for ; Thu, 15 Aug 2013 19:15:43 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F02E11E81AA for ; Thu, 15 Aug 2013 19:15:43 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7G2FgJP006459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Aug 2013 02:15:43 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7G2FfFu025979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 02:15:42 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7G2Ffij025971; Fri, 16 Aug 2013 02:15:41 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Aug 2013 19:15:41 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.com> Date: Thu, 15 Aug 2013 22:15:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! com> To: "Dwight, Timothy M (Tim)" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 02:15:49 -0000 I may be misunderstanding you, but I think we're kind of getting a = solution to that... though maybe not in a way that people want. For sake of argument, let's ignore the technology or any proposed = solution for STIR, or even STIR in general. Also ignore the existing = CNAM business model and pretend we wanted to provide CNAM for the first = time, from scratch. We know we can't just trust callerid4u to claim any CNAM it wanted to. = So let's say instead of trusting callerid4u, we designated some common = CA to verify and sign CNAM information for everyone, and everyone has to = trust them. This CA used various sources of information and = verification to create a "certificate" that said "for this phone number = X, the user's name is Jane Doe", or maybe "for the holder of the private = key for this public key, the user's name is Jane Doe" (which is = basically what web certificates say). So then we look at how to put this into SIP, and instead of putting the = whole certificate in the INVITE, we use an external database lookup = mechanism. That's basically STIR, for the phone number part. And the = existing CNAM databases are basically the "CA", where they provide a = trusted lookup database of phone-number -> CNAM. Since STIR validates = the phone number, the CNAM database lookup should be valid... assuming = you trust the CNAM database to be valid to begin with. But if you = *don't* trust it, it's not clear why you'd trust any other CA either. So we already have (or will once we have STIR) a way to get a fairly = valid CNAM, if you believe in a CA model for that. What we don't have = is a different pricing/business model for how the "CA" charges for = retrieving the "certificate" data. But I don't think it's the = technology that causes this really, so it's not something we can fix = here. I mean even web CAs charge an impressive amount of money for web = certificates, and the technology part of the job is trivial for them, = afaik. They charge what they believe the market will bear. -hadriel On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" = wrote: > With respect, I think statements like " I don't see how signing helps = " put the cart before the horse. Signing is an attribute of a possible = solution, not a requirement. =20 >=20 > It is precisely the www.callerid4u.com scenario you note, that worries = me. ISTM that if we declare any sort of validation for calling name to = be out of scope, we provide no solution to the victims of scams enabled = by services that allow dishonest actors to associate the name of a bank = with their phone number. >=20 > I recognize that names are not delegated in the same way that numbers = are, and that there are all sorts of semantic nuances that make their = validation difficult. Still, CA's do it. And it's been proposed on = this list that a smartphone app could do it. So I don't see why we're = so quick to agree we can't do it. Or at least, do something. =20 >=20 > I'm a pragmatist. Maybe we can't do as good a job validating names as = we can numbers. I still think it's better to make things better than to = do nothing. For example ISTM it'd be positive progress to enable the = called party to make a more informed decision about whether to trust the = calling name, than he can today. >=20 > tim >=20 > p.s. I tend to agree with Rich, that we can't forever duck the issue = of what gets presented to the called party. Whether it's addressed = directly or not, we're already making assumptions about what is and = isn't reasonable. =20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Henning Schulzrinne > Sent: Wednesday, August 14, 2013 2:19 PM > To: 'Paul Kyzivat'; Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) >=20 > Just piling on... There are at least three levels of information here, = making it difficult to do that within the signaling framework: >=20 > * the name of the person calling (vs. the subscriber name) > * the name of the organization > * properties of the organization ("licensed plumber", "FDIC-insured = bank", "located in Washington, DC", "registered charity") >=20 > This is more whois-like information than just the SIP display name. In = the certificate space, we have two levels: (1) assertion of domain name = control; (2) EV (extended validation) certs. It would be interesting to = see how well the EV concept has worked out in practice. >=20 > I don't see how signing helps here at all, for the reasons mentioned. = Nefarious actors can use services such as http://www.callerid4u.com/ to = use a legitimate number with just about any name string. And for = corporate accounts, the service provider has no way of knowing whether = Tom Sawyer is really at a particular number in a range and whether that = entity prefers to list the name of the person, just the organization, = the location ("PizzaHut Leonia") or something else. Indeed, the same = number can legitimately have multiple display names that change quickly = over time (e.g., staff at the doctor's office). >=20 > Verifiable whois-like information could be very useful and service = providers could see that as an opportunity, given that they do know a = lot about their customers, such as their billing and service address and = how long they have been in business. But it's a separate problem, = probably more closely related to the number allocation problem. >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Paul Kyzivat > Sent: Wednesday, August 14, 2013 3:04 PM > To: Brian Rosen > Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, = PENN L > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) >=20 > On 8/14/13 8:38 PM, Brian Rosen wrote: >> I suppose it's possible, but what is the criteria for validation? >>=20 >> With TNs, we have credentials that accompany number delegation - we=20= >> have a clear path to assuring that the caller asserting the identity=20= >> is indeed entitled to claim control of that number (well, SPs mostly,=20= >> not the caller, at least initially). There is no equivalent = assurance=20 >> for CNAM. >>=20 >> I don't want to get into a fight over which database is better, but=20= >> the alternate, doesn't depend on the origination carrier mechansism = is=20 >> statisically actually a better "validation" of the content than what = a=20 >> traditional carrier gets in his service order (because they usually=20= >> don't actually validate the content), and is infiniately better than=20= >> the carriers that allow the consumer to put anything they want in the=20= >> database. Without a reasonable way to assure that the database is=20 >> actually valid, what is the value of carrying an assertion? >=20 > While I recognize that letting the customer put in whatever they want = is problematic, I have no idea whether the alternative of letting the = CNAM provider include whatever they want is "better". (How would we = measure > that?) >=20 > (I've just been trying to deal with an "information aggregator" that = is publishing wrong information about me and won't change it. So I'm not = feeling good about that sort of thing.) >=20 > ISTM that is is yet another example of ancient, informal, manual = systems, that once mostly "worked" based on the good will of the people = involved, but that have now been automated into monstrosities that = nobody understands. (Management of healthcare data is another example.) >=20 > Ultimately there will need to be a big effort to develop a formal = framework for this. And it will probably require the creation of new = laws. >=20 > Alternatively this could be left to the open market. (E.g., The callee = could just Google the calling number.) >=20 > In any case STIR can't go down this rat hole. >=20 > Thanks, > Paul >=20 >> If we had such a mechanism, what prevents one of the carriers that=20 >> let's you put anything you want in the database from asserting that=20= >> the content of P-A-ID is valid, when the user is allowed to say=20 >> whatever they want goes in P-A-ID? >>=20 >> The best thing I can come up with would be to have some independent=20= >> validation service that used other data sources to validate the=20 >> content, and let them sign it. Then we could carry that signature = somewhere. >>=20 >> Right now, I think we should leave it out of scope. If we can figure=20= >> out a way to do validation, then we can revisit the notion of = carrying=20 >> evidence of validation in future work. >>=20 >> Does argue for making sure that whatever mechanism we arrive at = should=20 >> have some obvious extension mechanism, perhaps along the lines of = what=20 >> Jon was suggesting for media properties. If you recall, he proposed=20= >> to have a digest of SDP where the digest was protected by the=20 >> signature, but if the SDP received didn't match the SDP sent, the=20 >> termination side could know that, but the basic identity mechanism=20 >> could succeed anyway (that is, you knew you had a valid identity and = a modified SDP). >>=20 >> Brian >>=20 >> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>=20 >> Would it be possible to provide an indication of whether the = calling >> name was validated (in the same sense that the calling number was >> validated, but an independent indication)?____ >>=20 >> __ __ >>=20 >> ISTM that should be a simple exercise, protocol-wise. And it >> maintains the parallel treatment of name and number that we have >> today (e.g., there are today separate indications of privacy, for >> name and number). But that's not my main concern; mostly I'm >> thinking of the evolution of the process by which calling name is >> provided. Even if it's not possible to validate calling name as >> provided by CNAM, it might be possible to validate calling name as >> provided by other methods; e.g., by the calling network in the >> display-name header field in the FROM or (more likely in public >> networks) the P-A-ID header.____ >>=20 >> __ __ >>=20 >> tim____ >>=20 >> __ __ >>=20 >> __ __ >>=20 >> *From:*stir-bounces@ietf.org > 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >> ] *On Behalf = Of >> *PFAUTZ, PENN L >> *Sent:* Wednesday, August 14, 2013 9:37 AM >> *To:* Brian Rosen; Hadriel Kaplan >> *Cc:* stir@ietf.org ; >> Paul Kyzivat >> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter)____ >>=20 >> __ __ >>=20 >> I assume the concern in this thread is with the case where a = number >> might be authenticated but the CNAM displayed would be misleading >> because of lax policies of the CNAM provider - e.g., the bad guy >> makes a call from what is indeed his legit number but has managed = to >> get Bank of America into his CNAM entry.____ >>=20 >> __ __ >>=20 >> I'm thinking that taking on CNAM in the ietf may be a bridge too = far >> for stir. Leave what happens after the number is validated up to >> national authorities since arrangements may differ. And at least = in >> the case above it should be possible to trace back to the=20 >> perp.____ >>=20 >> __ __ >>=20 >> More generally I think the object of stir ought to be just to >> provide the customer an indication of whether the calling number = was >> validated on not - whether calls get blocked or unvalidated = numbers >> are still displayed should be up to the customer and their service >> provider.____ >>=20 >> __ __ >>=20 >> Penn Pfautz____ >>=20 >> AT&T Access Management____ >>=20 >> +1-732-420-4962____ >>=20 >> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >> Behalf Of *Brian Rosen >> *Sent:* Wednesday, August 14, 2013 9:32 AM >> *To:* Hadriel Kaplan >> *Cc:* stir@ietf.org; Paul Kyzivat >> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter)____ >>=20 >> __ __ >>=20 >> I think we probably should keep CNAM out of this for now=20 >> anyway.____ >>=20 >> __ __ >>=20 >> The advantage of the credential delegation process as we have >> defined it is that it's authoritative.____ >>=20 >> __ __ >>=20 >> The current CNAM databases cannot be called "authoritative" = really. >> Classically, as you describe, there is a database operated by on >> on behalf of the origination carrier and queried by the = termination >> carrier (often with a charge to query). The content is what the >> carrier has recorde from the original service order, but there = isn't >> any attempt to validate those names, and there are carriers who = will >> let you put anything you like in there. How "authoritative" is >> that? Then there are other databases, like Neustar's, that don't >> have any relationship to the originination carrier - the = termination >> carrier dips an independently developed database of name-number >> relationships. These databases are developed using a wide variety >> of sources and have evolved to be very accurate, but hardly >> "authoritative".____ >>=20 >> __ __ >>=20 >> And yes, Hadriel, there are regulatory restrictions, mostly about >> what the NPAC (number portability database administrator) can do. >> The CNAM databases have very few regulations to deal with.____ >>=20 >> __ __ >>=20 >> Brian ____ >>=20 >>=20 >> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>=20 >>=20 >> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Thu Aug 15 22:09:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F0F11E810D for ; Thu, 15 Aug 2013 22:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=1.247, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhJQ1s1TfI1I for ; Thu, 15 Aug 2013 22:09:27 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6812C11E80DF for ; Thu, 15 Aug 2013 22:09:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 16 Aug 2013 05:09:22 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,891,1367971200"; d="scan'208";a="527768525" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 16 Aug 2013 05:09:21 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Fri, 16 Aug 2013 01:09:21 -0400 To: Hadriel Kaplan Date: Fri, 16 Aug 2013 01:09:20 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: Ac6aJoTYBCqMdb2bSqeovIWPzYzCxwAFgrJw Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> In-Reply-To: <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 05:09:47 -0000 The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers can and= do run their own LIDBs. As do all sorts of 3rd parties, who get informati= on from God-only-knows where, about individuals with whom they have no busi= ness relationship (so, no incentive to "keep happy"). Providing a validated calling number would not protect my mom from a scamme= r who's got a number from such a "dodgy" carrier, and has been allowed by t= hat carrier to associate with it the name of her bank. AFAICT it only help= s entities that operate their own identity database, e.g., LEAs and PSAPs. tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Thursday, August 15, 2013 9:16 PM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I may be misunderstanding you, but I think we're kind of getting a solution= to that... though maybe not in a way that people want. For sake of argument, let's ignore the technology or any proposed solution = for STIR, or even STIR in general. Also ignore the existing CNAM business = model and pretend we wanted to provide CNAM for the first time, from scratc= h. We know we can't just trust callerid4u to claim any CNAM it wanted to. So = let's say instead of trusting callerid4u, we designated some common CA to v= erify and sign CNAM information for everyone, and everyone has to trust the= m. This CA used various sources of information and verification to create = a "certificate" that said "for this phone number X, the user's name is Jane= Doe", or maybe "for the holder of the private key for this public key, the= user's name is Jane Doe" (which is basically what web certificates say). So then we look at how to put this into SIP, and instead of putting the who= le certificate in the INVITE, we use an external database lookup mechanism.= That's basically STIR, for the phone number part. And the existing CNAM = databases are basically the "CA", where they provide a trusted lookup datab= ase of phone-number -> CNAM. Since STIR validates the phone number, the CN= AM database lookup should be valid... assuming you trust the CNAM database = to be valid to begin with. But if you *don't* trust it, it's not clear why= you'd trust any other CA either. So we already have (or will once we have STIR) a way to get a fairly valid = CNAM, if you believe in a CA model for that. What we don't have is a diffe= rent pricing/business model for how the "CA" charges for retrieving the "ce= rtificate" data. But I don't think it's the technology that causes this re= ally, so it's not something we can fix here. I mean even web CAs charge an= impressive amount of money for web certificates, and the technology part o= f the job is trivial for them, afaik. They charge what they believe the ma= rket will bear. -hadriel On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > With respect, I think statements like " I don't see how signing helps " p= ut the cart before the horse. Signing is an attribute of a possible soluti= on, not a requirement. > > It is precisely the www.callerid4u.com scenario you note, that worries me= . ISTM that if we declare any sort of validation for calling name to be ou= t of scope, we provide no solution to the victims of scams enabled by servi= ces that allow dishonest actors to associate the name of a bank with their = phone number. > > I recognize that names are not delegated in the same way that numbers are= , and that there are all sorts of semantic nuances that make their validati= on difficult. Still, CA's do it. And it's been proposed on this list that= a smartphone app could do it. So I don't see why we're so quick to agree = we can't do it. Or at least, do something. > > I'm a pragmatist. Maybe we can't do as good a job validating names as we= can numbers. I still think it's better to make things better than to do n= othing. For example ISTM it'd be positive progress to enable the called pa= rty to make a more informed decision about whether to trust the calling nam= e, than he can today. > > tim > > p.s. I tend to agree with Rich, that we can't forever duck the issue of w= hat gets presented to the called party. Whether it's addressed directly or= not, we're already making assumptions about what is and isn't reasonable. > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Henning Schulzrinne > Sent: Wednesday, August 14, 2013 2:19 PM > To: 'Paul Kyzivat'; Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > Just piling on... There are at least three levels of information here, ma= king it difficult to do that within the signaling framework: > > * the name of the person calling (vs. the subscriber name) > * the name of the organization > * properties of the organization ("licensed plumber", "FDIC-insured > bank", "located in Washington, DC", "registered charity") > > This is more whois-like information than just the SIP display name. In th= e certificate space, we have two levels: (1) assertion of domain name contr= ol; (2) EV (extended validation) certs. It would be interesting to see how = well the EV concept has worked out in practice. > > I don't see how signing helps here at all, for the reasons mentioned. Nef= arious actors can use services such as http://www.callerid4u.com/ to use a = legitimate number with just about any name string. And for corporate accoun= ts, the service provider has no way of knowing whether Tom Sawyer is really= at a particular number in a range and whether that entity prefers to list = the name of the person, just the organization, the location ("PizzaHut Leon= ia") or something else. Indeed, the same number can legitimately have multi= ple display names that change quickly over time (e.g., staff at the doctor'= s office). > > Verifiable whois-like information could be very useful and service provid= ers could see that as an opportunity, given that they do know a lot about t= heir customers, such as their billing and service address and how long they= have been in business. But it's a separate problem, probably more closely = related to the number allocation problem. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, August 14, 2013 3:04 PM > To: Brian Rosen > Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, > PENN L > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > On 8/14/13 8:38 PM, Brian Rosen wrote: >> I suppose it's possible, but what is the criteria for validation? >> >> With TNs, we have credentials that accompany number delegation - we >> have a clear path to assuring that the caller asserting the identity >> is indeed entitled to claim control of that number (well, SPs mostly, >> not the caller, at least initially). There is no equivalent >> assurance for CNAM. >> >> I don't want to get into a fight over which database is better, but >> the alternate, doesn't depend on the origination carrier mechansism >> is statisically actually a better "validation" of the content than >> what a traditional carrier gets in his service order (because they >> usually don't actually validate the content), and is infiniately >> better than the carriers that allow the consumer to put anything they >> want in the database. Without a reasonable way to assure that the >> database is actually valid, what is the value of carrying an assertion? > > While I recognize that letting the customer put in whatever they want > is problematic, I have no idea whether the alternative of letting the > CNAM provider include whatever they want is "better". (How would we > measure > that?) > > (I've just been trying to deal with an "information aggregator" that > is publishing wrong information about me and won't change it. So I'm > not feeling good about that sort of thing.) > > ISTM that is is yet another example of ancient, informal, manual > systems, that once mostly "worked" based on the good will of the > people involved, but that have now been automated into monstrosities > that nobody understands. (Management of healthcare data is another > example.) > > Ultimately there will need to be a big effort to develop a formal framewo= rk for this. And it will probably require the creation of new laws. > > Alternatively this could be left to the open market. (E.g., The callee > could just Google the calling number.) > > In any case STIR can't go down this rat hole. > > Thanks, > Paul > >> If we had such a mechanism, what prevents one of the carriers that >> let's you put anything you want in the database from asserting that >> the content of P-A-ID is valid, when the user is allowed to say >> whatever they want goes in P-A-ID? >> >> The best thing I can come up with would be to have some independent >> validation service that used other data sources to validate the >> content, and let them sign it. Then we could carry that signature somew= here. >> >> Right now, I think we should leave it out of scope. If we can figure >> out a way to do validation, then we can revisit the notion of >> carrying evidence of validation in future work. >> >> Does argue for making sure that whatever mechanism we arrive at >> should have some obvious extension mechanism, perhaps along the lines >> of what Jon was suggesting for media properties. If you recall, he >> proposed to have a digest of SDP where the digest was protected by >> the signature, but if the SDP received didn't match the SDP sent, the >> termination side could know that, but the basic identity mechanism >> could succeed anyway (that is, you knew you had a valid identity and a m= odified SDP). >> >> Brian >> >> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >> >> Would it be possible to provide an indication of whether the calling >> name was validated (in the same sense that the calling number was >> validated, but an independent indication)?____ >> >> __ __ >> >> ISTM that should be a simple exercise, protocol-wise. And it >> maintains the parallel treatment of name and number that we have >> today (e.g., there are today separate indications of privacy, for >> name and number). But that's not my main concern; mostly I'm >> thinking of the evolution of the process by which calling name is >> provided. Even if it's not possible to validate calling name as >> provided by CNAM, it might be possible to validate calling name as >> provided by other methods; e.g., by the calling network in the >> display-name header field in the FROM or (more likely in public >> networks) the P-A-ID header.____ >> >> __ __ >> >> tim____ >> >> __ __ >> >> __ __ >> >> *From:*stir-bounces@ietf.org > 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >> ] *On Behalf Of >> *PFAUTZ, PENN L >> *Sent:* Wednesday, August 14, 2013 9:37 AM >> *To:* Brian Rosen; Hadriel Kaplan >> *Cc:* stir@ietf.org ; >> Paul Kyzivat >> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter)____ >> >> __ __ >> >> I assume the concern in this thread is with the case where a number >> might be authenticated but the CNAM displayed would be misleading >> because of lax policies of the CNAM provider - e.g., the bad guy >> makes a call from what is indeed his legit number but has managed to >> get Bank of America into his CNAM entry.____ >> >> __ __ >> >> I'm thinking that taking on CNAM in the ietf may be a bridge too far >> for stir. Leave what happens after the number is validated up to >> national authorities since arrangements may differ. And at least in >> the case above it should be possible to trace back to the >> perp.____ >> >> __ __ >> >> More generally I think the object of stir ought to be just to >> provide the customer an indication of whether the calling number was >> validated on not - whether calls get blocked or unvalidated numbers >> are still displayed should be up to the customer and their service >> provider.____ >> >> __ __ >> >> Penn Pfautz____ >> >> AT&T Access Management____ >> >> +1-732-420-4962____ >> >> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >> Behalf Of *Brian Rosen >> *Sent:* Wednesday, August 14, 2013 9:32 AM >> *To:* Hadriel Kaplan >> *Cc:* stir@ietf.org; Paul Kyzivat >> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter)____ >> >> __ __ >> >> I think we probably should keep CNAM out of this for now >> anyway.____ >> >> __ __ >> >> The advantage of the credential delegation process as we have >> defined it is that it's authoritative.____ >> >> __ __ >> >> The current CNAM databases cannot be called "authoritative" really. >> Classically, as you describe, there is a database operated by on >> on behalf of the origination carrier and queried by the termination >> carrier (often with a charge to query). The content is what the >> carrier has recorde from the original service order, but there isn't >> any attempt to validate those names, and there are carriers who will >> let you put anything you like in there. How "authoritative" is >> that? Then there are other databases, like Neustar's, that don't >> have any relationship to the originination carrier - the termination >> carrier dips an independently developed database of name-number >> relationships. These databases are developed using a wide variety >> of sources and have evolved to be very accurate, but hardly >> "authoritative".____ >> >> __ __ >> >> And yes, Hadriel, there are regulatory restrictions, mostly about >> what the NPAC (number portability database administrator) can do. >> The CNAM databases have very few regulations to deal with.____ >> >> __ __ >> >> Brian ____ >> >> >> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >> >> >> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Fri Aug 16 04:28:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7963E11E814B for ; Fri, 16 Aug 2013 04:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J54vbZhqBf3N for ; Fri, 16 Aug 2013 04:28:48 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4094F11E8146 for ; Fri, 16 Aug 2013 04:28:48 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7GBSkIX023960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Aug 2013 11:28:47 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7GBSj2I020579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 11:28:46 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7GBSjjI006591; Fri, 16 Aug 2013 11:28:45 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Aug 2013 04:28:44 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> Date: Fri, 16 Aug 2013 07:28:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> To: "Dwight, Timothy M (Tim)" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 11:28:53 -0000 So what that says to me is you can't trust a CA - or at least not all = the "CAs". I've been told that some CNAM DB providers don't just = blindly believe LIDB entries, but actually perform cross-reference = checking with other data. (if they even populated the data from LIDB to = begin with) But that's one of the reasons it feels logical to me to keep it in a = separate 3rd-party database, because you can't just trust what comes in = on SIP/SS7 - you need a third party to perform some = verification/cross-checking of the data, and in-advance as opposed to = just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call = originator and terminator - for that you don't need STIR nor 3rd party = CNAM databases) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" = wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers = can and do run their own LIDBs. As do all sorts of 3rd parties, who get = information from God-only-knows where, about individuals with whom they = have no business relationship (so, no incentive to "keep happy"). >=20 > Providing a validated calling number would not protect my mom from a = scammer who's got a number from such a "dodgy" carrier, and has been = allowed by that carrier to associate with it the name of her bank. = AFAICT it only helps entities that operate their own identity database, = e.g., LEAs and PSAPs. >=20 > tim >=20 >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) >=20 >=20 > I may be misunderstanding you, but I think we're kind of getting a = solution to that... though maybe not in a way that people want. >=20 > For sake of argument, let's ignore the technology or any proposed = solution for STIR, or even STIR in general. Also ignore the existing = CNAM business model and pretend we wanted to provide CNAM for the first = time, from scratch. >=20 > We know we can't just trust callerid4u to claim any CNAM it wanted to. = So let's say instead of trusting callerid4u, we designated some common = CA to verify and sign CNAM information for everyone, and everyone has to = trust them. This CA used various sources of information and = verification to create a "certificate" that said "for this phone number = X, the user's name is Jane Doe", or maybe "for the holder of the private = key for this public key, the user's name is Jane Doe" (which is = basically what web certificates say). >=20 > So then we look at how to put this into SIP, and instead of putting = the whole certificate in the INVITE, we use an external database lookup = mechanism. That's basically STIR, for the phone number part. And the = existing CNAM databases are basically the "CA", where they provide a = trusted lookup database of phone-number -> CNAM. Since STIR validates = the phone number, the CNAM database lookup should be valid... assuming = you trust the CNAM database to be valid to begin with. But if you = *don't* trust it, it's not clear why you'd trust any other CA either. >=20 > So we already have (or will once we have STIR) a way to get a fairly = valid CNAM, if you believe in a CA model for that. What we don't have = is a different pricing/business model for how the "CA" charges for = retrieving the "certificate" data. But I don't think it's the = technology that causes this really, so it's not something we can fix = here. I mean even web CAs charge an impressive amount of money for web = certificates, and the technology part of the job is trivial for them, = afaik. They charge what they believe the market will bear. >=20 > -hadriel >=20 >=20 > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" = wrote: >=20 >> With respect, I think statements like " I don't see how signing helps = " put the cart before the horse. Signing is an attribute of a possible = solution, not a requirement. >>=20 >> It is precisely the www.callerid4u.com scenario you note, that = worries me. ISTM that if we declare any sort of validation for calling = name to be out of scope, we provide no solution to the victims of scams = enabled by services that allow dishonest actors to associate the name of = a bank with their phone number. >>=20 >> I recognize that names are not delegated in the same way that numbers = are, and that there are all sorts of semantic nuances that make their = validation difficult. Still, CA's do it. And it's been proposed on = this list that a smartphone app could do it. So I don't see why we're = so quick to agree we can't do it. Or at least, do something. >>=20 >> I'm a pragmatist. Maybe we can't do as good a job validating names = as we can numbers. I still think it's better to make things better than = to do nothing. For example ISTM it'd be positive progress to enable the = called party to make a more informed decision about whether to trust the = calling name, than he can today. >>=20 >> tim >>=20 >> p.s. I tend to agree with Rich, that we can't forever duck the issue = of what gets presented to the called party. Whether it's addressed = directly or not, we're already making assumptions about what is and = isn't reasonable. >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >>=20 >> Just piling on... There are at least three levels of information = here, making it difficult to do that within the signaling framework: >>=20 >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured >> bank", "located in Washington, DC", "registered charity") >>=20 >> This is more whois-like information than just the SIP display name. = In the certificate space, we have two levels: (1) assertion of domain = name control; (2) EV (extended validation) certs. It would be = interesting to see how well the EV concept has worked out in practice. >>=20 >> I don't see how signing helps here at all, for the reasons mentioned. = Nefarious actors can use services such as http://www.callerid4u.com/ to = use a legitimate number with just about any name string. And for = corporate accounts, the service provider has no way of knowing whether = Tom Sawyer is really at a particular number in a range and whether that = entity prefers to list the name of the person, just the organization, = the location ("PizzaHut Leonia") or something else. Indeed, the same = number can legitimately have multiple display names that change quickly = over time (e.g., staff at the doctor's office). >>=20 >> Verifiable whois-like information could be very useful and service = providers could see that as an opportunity, given that they do know a = lot about their customers, such as their billing and service address and = how long they have been in business. But it's a separate problem, = probably more closely related to the number allocation problem. >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >>=20 >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>>=20 >>> With TNs, we have credentials that accompany number delegation - we >>> have a clear path to assuring that the caller asserting the identity >>> is indeed entitled to claim control of that number (well, SPs = mostly, >>> not the caller, at least initially). There is no equivalent >>> assurance for CNAM. >>>=20 >>> I don't want to get into a fight over which database is better, but >>> the alternate, doesn't depend on the origination carrier mechansism >>> is statisically actually a better "validation" of the content than >>> what a traditional carrier gets in his service order (because they >>> usually don't actually validate the content), and is infiniately >>> better than the carriers that allow the consumer to put anything = they >>> want in the database. Without a reasonable way to assure that the >>> database is actually valid, what is the value of carrying an = assertion? >>=20 >> While I recognize that letting the customer put in whatever they want >> is problematic, I have no idea whether the alternative of letting the >> CNAM provider include whatever they want is "better". (How would we >> measure >> that?) >>=20 >> (I've just been trying to deal with an "information aggregator" that >> is publishing wrong information about me and won't change it. So I'm >> not feeling good about that sort of thing.) >>=20 >> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good will of the >> people involved, but that have now been automated into monstrosities >> that nobody understands. (Management of healthcare data is another >> example.) >>=20 >> Ultimately there will need to be a big effort to develop a formal = framework for this. And it will probably require the creation of new = laws. >>=20 >> Alternatively this could be left to the open market. (E.g., The = callee >> could just Google the calling number.) >>=20 >> In any case STIR can't go down this rat hole. >>=20 >> Thanks, >> Paul >>=20 >>> If we had such a mechanism, what prevents one of the carriers that >>> let's you put anything you want in the database from asserting that >>> the content of P-A-ID is valid, when the user is allowed to say >>> whatever they want goes in P-A-ID? >>>=20 >>> The best thing I can come up with would be to have some independent >>> validation service that used other data sources to validate the >>> content, and let them sign it. Then we could carry that signature = somewhere. >>>=20 >>> Right now, I think we should leave it out of scope. If we can = figure >>> out a way to do validation, then we can revisit the notion of >>> carrying evidence of validation in future work. >>>=20 >>> Does argue for making sure that whatever mechanism we arrive at >>> should have some obvious extension mechanism, perhaps along the = lines >>> of what Jon was suggesting for media properties. If you recall, he >>> proposed to have a digest of SDP where the digest was protected by >>> the signature, but if the SDP received didn't match the SDP sent, = the >>> termination side could know that, but the basic identity mechanism >>> could succeed anyway (that is, you knew you had a valid identity and = a modified SDP). >>>=20 >>> Brian >>>=20 >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>>=20 >>> Would it be possible to provide an indication of whether the = calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>>=20 >>> __ __ >>>=20 >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>>=20 >>> __ __ >>>=20 >>> tim____ >>>=20 >>> __ __ >>>=20 >>> __ __ >>>=20 >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf = Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>>=20 >>> __ __ >>>=20 >>> I assume the concern in this thread is with the case where a = number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed = to >>> get Bank of America into his CNAM entry.____ >>>=20 >>> __ __ >>>=20 >>> I'm thinking that taking on CNAM in the ietf may be a bridge too = far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least = in >>> the case above it should be possible to trace back to the >>> perp.____ >>>=20 >>> __ __ >>>=20 >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number = was >>> validated on not - whether calls get blocked or unvalidated = numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>>=20 >>> __ __ >>>=20 >>> Penn Pfautz____ >>>=20 >>> AT&T Access Management____ >>>=20 >>> +1-732-420-4962____ >>>=20 >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>>=20 >>> __ __ >>>=20 >>> I think we probably should keep CNAM out of this for now >>> anyway.____ >>>=20 >>> __ __ >>>=20 >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>>=20 >>> __ __ >>>=20 >>> The current CNAM databases cannot be called "authoritative" = really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the = termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there = isn't >>> any attempt to validate those names, and there are carriers who = will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the = termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>>=20 >>> __ __ >>>=20 >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>>=20 >>> __ __ >>>=20 >>> Brian ____ >>>=20 >>>=20 >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>>=20 >>>=20 >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Fri Aug 16 06:30:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFF921F9A81 for ; Fri, 16 Aug 2013 06:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVsBTPxjla+n for ; Fri, 16 Aug 2013 06:30:20 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id AF83421F9A72 for ; Fri, 16 Aug 2013 06:30:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe01.verizonbusiness.com with ESMTP; 16 Aug 2013 13:30:17 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,895,1367971200"; d="scan'208";a="537964694" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 16 Aug 2013 13:30:15 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Fri, 16 Aug 2013 09:30:15 -0400 To: Hadriel Kaplan Date: Fri, 16 Aug 2013 09:30:13 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: Ac6ac8gs8CjIJoONSjOCnzA7Z7MwJQAC/TXw Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@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 Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 13:30:25 -0000 The ability to "cross-check" or otherwise validate the contents of a databa= se, is not unique to "3rd parties". It baffles me why involving a 3rd part= y would be expected to make things better. AFAICS the service provider and= the 3rd party are equally capable of being vigilent with respect to the co= ntent of their database; but the service provider is uniquely positioned by= virtue of his ongoing business relationship with the calling party. That = relationship gives him greater access to information about the customer's i= dentity, and more incentive to manage it properly, than a 3rd party would h= ave. That doesn't eliminate the potential for "dodgy" service providers. Obviou= sly. But 3rd party database providers have the same potential to be "dodgy= ", and less incentive not to be. I wish that last comment were true, but I don't think it is. The problem i= s that "dodgy" entities typically interconnect to the PSTN via wholesale se= rvices provided by a "traditional" carrier. To exchange traffic with them = you go through their wholesale provider. Even if A and B directly intercon= nect, and neither is the least bit "dodgy", there may be sitting behind one= or both of them, carriers that are. Even if A and B trust one another com= pletely I think they would still want to be protected from one anothers' wh= olesale customers. And besides, in business nobody ever trusts anybody com= pletely :-). tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, August 16, 2013 6:29 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) So what that says to me is you can't trust a CA - or at least not all the "= CAs". I've been told that some CNAM DB providers don't just blindly believ= e LIDB entries, but actually perform cross-reference checking with other da= ta. (if they even populated the data from LIDB to begin with) But that's one of the reasons it feels logical to me to keep it in a separa= te 3rd-party database, because you can't just trust what comes in on SIP/SS= 7 - you need a third party to perform some verification/cross-checking of t= he data, and in-advance as opposed to just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call originat= or and terminator - for that you don't need STIR nor 3rd party CNAM databas= es) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers can a= nd do run their own LIDBs. As do all sorts of 3rd parties, who get informa= tion from God-only-knows where, about individuals with whom they have no bu= siness relationship (so, no incentive to "keep happy"). > > Providing a validated calling number would not protect my mom from a scam= mer who's got a number from such a "dodgy" carrier, and has been allowed by= that carrier to associate with it the name of her bank. AFAICT it only he= lps entities that operate their own identity database, e.g., LEAs and PSAPs= . > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > > I may be misunderstanding you, but I think we're kind of getting a soluti= on to that... though maybe not in a way that people want. > > For sake of argument, let's ignore the technology or any proposed solutio= n for STIR, or even STIR in general. Also ignore the existing CNAM busines= s model and pretend we wanted to provide CNAM for the first time, from scra= tch. > > We know we can't just trust callerid4u to claim any CNAM it wanted to. S= o let's say instead of trusting callerid4u, we designated some common CA to= verify and sign CNAM information for everyone, and everyone has to trust t= hem. This CA used various sources of information and verification to creat= e a "certificate" that said "for this phone number X, the user's name is Ja= ne Doe", or maybe "for the holder of the private key for this public key, t= he user's name is Jane Doe" (which is basically what web certificates say). > > So then we look at how to put this into SIP, and instead of putting the w= hole certificate in the INVITE, we use an external database lookup mechanis= m. That's basically STIR, for the phone number part. And the existing CNA= M databases are basically the "CA", where they provide a trusted lookup dat= abase of phone-number -> CNAM. Since STIR validates the phone number, the = CNAM database lookup should be valid... assuming you trust the CNAM databas= e to be valid to begin with. But if you *don't* trust it, it's not clear w= hy you'd trust any other CA either. > > So we already have (or will once we have STIR) a way to get a fairly vali= d CNAM, if you believe in a CA model for that. What we don't have is a dif= ferent pricing/business model for how the "CA" charges for retrieving the "= certificate" data. But I don't think it's the technology that causes this = really, so it's not something we can fix here. I mean even web CAs charge = an impressive amount of money for web certificates, and the technology part= of the job is trivial for them, afaik. They charge what they believe the = market will bear. > > -hadriel > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > >> With respect, I think statements like " I don't see how signing helps " = put the cart before the horse. Signing is an attribute of a possible solut= ion, not a requirement. >> >> It is precisely the www.callerid4u.com scenario you note, that worries m= e. ISTM that if we declare any sort of validation for calling name to be o= ut of scope, we provide no solution to the victims of scams enabled by serv= ices that allow dishonest actors to associate the name of a bank with their= phone number. >> >> I recognize that names are not delegated in the same way that numbers ar= e, and that there are all sorts of semantic nuances that make their validat= ion difficult. Still, CA's do it. And it's been proposed on this list tha= t a smartphone app could do it. So I don't see why we're so quick to agree= we can't do it. Or at least, do something. >> >> I'm a pragmatist. Maybe we can't do as good a job validating names as w= e can numbers. I still think it's better to make things better than to do = nothing. For example ISTM it'd be positive progress to enable the called p= arty to make a more informed decision about whether to trust the calling na= me, than he can today. >> >> tim >> >> p.s. I tend to agree with Rich, that we can't forever duck the issue of = what gets presented to the called party. Whether it's addressed directly o= r not, we're already making assumptions about what is and isn't reasonable. >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> Just piling on... There are at least three levels of information here, m= aking it difficult to do that within the signaling framework: >> >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured >> bank", "located in Washington, DC", "registered charity") >> >> This is more whois-like information than just the SIP display name. In t= he certificate space, we have two levels: (1) assertion of domain name cont= rol; (2) EV (extended validation) certs. It would be interesting to see how= well the EV concept has worked out in practice. >> >> I don't see how signing helps here at all, for the reasons mentioned. Ne= farious actors can use services such as http://www.callerid4u.com/ to use a= legitimate number with just about any name string. And for corporate accou= nts, the service provider has no way of knowing whether Tom Sawyer is reall= y at a particular number in a range and whether that entity prefers to list= the name of the person, just the organization, the location ("PizzaHut Leo= nia") or something else. Indeed, the same number can legitimately have mult= iple display names that change quickly over time (e.g., staff at the doctor= 's office). >> >> Verifiable whois-like information could be very useful and service provi= ders could see that as an opportunity, given that they do know a lot about = their customers, such as their billing and service address and how long the= y have been in business. But it's a separate problem, probably more closely= related to the number allocation problem. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>> >>> With TNs, we have credentials that accompany number delegation - we >>> have a clear path to assuring that the caller asserting the identity >>> is indeed entitled to claim control of that number (well, SPs >>> mostly, not the caller, at least initially). There is no equivalent >>> assurance for CNAM. >>> >>> I don't want to get into a fight over which database is better, but >>> the alternate, doesn't depend on the origination carrier mechansism >>> is statisically actually a better "validation" of the content than >>> what a traditional carrier gets in his service order (because they >>> usually don't actually validate the content), and is infiniately >>> better than the carriers that allow the consumer to put anything >>> they want in the database. Without a reasonable way to assure that >>> the database is actually valid, what is the value of carrying an assert= ion? >> >> While I recognize that letting the customer put in whatever they want >> is problematic, I have no idea whether the alternative of letting the >> CNAM provider include whatever they want is "better". (How would we >> measure >> that?) >> >> (I've just been trying to deal with an "information aggregator" that >> is publishing wrong information about me and won't change it. So I'm >> not feeling good about that sort of thing.) >> >> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good will of the >> people involved, but that have now been automated into monstrosities >> that nobody understands. (Management of healthcare data is another >> example.) >> >> Ultimately there will need to be a big effort to develop a formal framew= ork for this. And it will probably require the creation of new laws. >> >> Alternatively this could be left to the open market. (E.g., The >> callee could just Google the calling number.) >> >> In any case STIR can't go down this rat hole. >> >> Thanks, >> Paul >> >>> If we had such a mechanism, what prevents one of the carriers that >>> let's you put anything you want in the database from asserting that >>> the content of P-A-ID is valid, when the user is allowed to say >>> whatever they want goes in P-A-ID? >>> >>> The best thing I can come up with would be to have some independent >>> validation service that used other data sources to validate the >>> content, and let them sign it. Then we could carry that signature some= where. >>> >>> Right now, I think we should leave it out of scope. If we can >>> figure out a way to do validation, then we can revisit the notion of >>> carrying evidence of validation in future work. >>> >>> Does argue for making sure that whatever mechanism we arrive at >>> should have some obvious extension mechanism, perhaps along the >>> lines of what Jon was suggesting for media properties. If you >>> recall, he proposed to have a digest of SDP where the digest was >>> protected by the signature, but if the SDP received didn't match the >>> SDP sent, the termination side could know that, but the basic >>> identity mechanism could succeed anyway (that is, you knew you had a va= lid identity and a modified SDP). >>> >>> Brian >>> >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>> >>> Would it be possible to provide an indication of whether the calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>> >>> __ __ >>> >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>> >>> __ __ >>> >>> tim____ >>> >>> __ __ >>> >>> __ __ >>> >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I assume the concern in this thread is with the case where a number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed to >>> get Bank of America into his CNAM entry.____ >>> >>> __ __ >>> >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least in >>> the case above it should be possible to trace back to the >>> perp.____ >>> >>> __ __ >>> >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number was >>> validated on not - whether calls get blocked or unvalidated numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>> >>> __ __ >>> >>> Penn Pfautz____ >>> >>> AT&T Access Management____ >>> >>> +1-732-420-4962____ >>> >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I think we probably should keep CNAM out of this for now >>> anyway.____ >>> >>> __ __ >>> >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>> >>> __ __ >>> >>> The current CNAM databases cannot be called "authoritative" really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there isn't >>> any attempt to validate those names, and there are carriers who will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>> >>> __ __ >>> >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>> >>> __ __ >>> >>> Brian ____ >>> >>> >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>> >>> >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Fri Aug 16 06:41:28 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF311E814E for ; Fri, 16 Aug 2013 06:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH1xxAzFwe52 for ; Fri, 16 Aug 2013 06:41:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1C19221F9E83 for ; Fri, 16 Aug 2013 06:41:10 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7GDf8tA018154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Aug 2013 13:41:09 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7GDf7M4002913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 13:41:08 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7GDf7CI008107; Fri, 16 Aug 2013 13:41:07 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Aug 2013 06:41:07 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> Date: Fri, 16 Aug 2013 09:41:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> To: "Dwight, Timothy M (Tim)" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 13:41:28 -0000 On Aug 16, 2013, at 9:30 AM, "Dwight, Timothy M (Tim)" = wrote: > The ability to "cross-check" or otherwise validate the contents of a = database, is not unique to "3rd parties". It baffles me why involving a = 3rd party would be expected to make things better. AFAICS the service = provider and the 3rd party are equally capable of being vigilent with = respect to the content of their database; but the service provider is = uniquely positioned by virtue of his ongoing business relationship with = the calling party. That relationship gives him greater access to = information about the customer's identity, and more incentive to manage = it properly, than a 3rd party would have. >=20 > That doesn't eliminate the potential for "dodgy" service providers. = Obviously. But 3rd party database providers have the same potential to = be "dodgy", and less incentive not to be. >=20 > I wish that last comment were true, but I don't think it is. The = problem is that "dodgy" entities typically interconnect to the PSTN via = wholesale services provided by a "traditional" carrier. To exchange = traffic with them you go through their wholesale provider. Even if A = and B directly interconnect, and neither is the least bit "dodgy", there = may be sitting behind one or both of them, carriers that are. Even if A = and B trust one another completely I think they would still want to be = protected from one anothers' wholesale customers. And besides, in = business nobody ever trusts anybody completely :-). Agreed, that last paragraph is basically the problem we have, even for = telephone numbers let alone CNAM. We've always known this would = eventually happen, once the cost of making phone calls and connecting to = the network-of-trust got cheap enough. The reason a 3rd party helps is = because there really is incentive for them to not lie: if they lie, the = "good" carriers won't use them and they won't be as valuable. Their = whole business model depends on their data being accurate. -hadriel From michael.hammer@yaanatech.com Fri Aug 16 06:45:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E04F21F9A33 for ; Fri, 16 Aug 2013 06:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYznzzDNxL9F for ; Fri, 16 Aug 2013 06:44:58 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1021F99DD for ; Fri, 16 Aug 2013 06:44:58 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 16 Aug 2013 06:44:57 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAAwhwCAAGoAgIAAIfKA//+NN+A= Date: Fri, 16 Aug 2013 13:44:56 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC29963@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.101] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0045_01CE9A65.4329A460" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 13:45:02 -0000 ------=_NextPart_000_0045_01CE9A65.4329A460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If that "3rd party" is really the 2nd party, i.e. the terminating phone, then it might just be trustworthy. The end user can learn what number to trust based on experience. All this discussion is interesting, but it all depends on the input to the CNAM lookup being accurate, no? Ensuring that the number is valid is Step 1, what I thought the focus of STIR is. All the rest of this is derivative. This sounds to me like a BOF discussion for a follow-on WG. And one that we could send all those concerned with privacy to. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Friday, August 16, 2013 9:30 AM To: Hadriel Kaplan Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) The ability to "cross-check" or otherwise validate the contents of a database, is not unique to "3rd parties". It baffles me why involving a 3rd party would be expected to make things better. AFAICS the service provider and the 3rd party are equally capable of being vigilent with respect to the content of their database; but the service provider is uniquely positioned by virtue of his ongoing business relationship with the calling party. That relationship gives him greater access to information about the customer's identity, and more incentive to manage it properly, than a 3rd party would have. That doesn't eliminate the potential for "dodgy" service providers. Obviously. But 3rd party database providers have the same potential to be "dodgy", and less incentive not to be. I wish that last comment were true, but I don't think it is. The problem is that "dodgy" entities typically interconnect to the PSTN via wholesale services provided by a "traditional" carrier. To exchange traffic with them you go through their wholesale provider. Even if A and B directly interconnect, and neither is the least bit "dodgy", there may be sitting behind one or both of them, carriers that are. Even if A and B trust one another completely I think they would still want to be protected from one anothers' wholesale customers. And besides, in business nobody ever trusts anybody completely :-). tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, August 16, 2013 6:29 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) So what that says to me is you can't trust a CA - or at least not all the "CAs". I've been told that some CNAM DB providers don't just blindly believe LIDB entries, but actually perform cross-reference checking with other data. (if they even populated the data from LIDB to begin with) But that's one of the reasons it feels logical to me to keep it in a separate 3rd-party database, because you can't just trust what comes in on SIP/SS7 - you need a third party to perform some verification/cross-checking of the data, and in-advance as opposed to just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call originator and terminator - for that you don't need STIR nor 3rd party CNAM databases) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers can and do run their own LIDBs. As do all sorts of 3rd parties, who get information from God-only-knows where, about individuals with whom they have no business relationship (so, no incentive to "keep happy"). > > Providing a validated calling number would not protect my mom from a scammer who's got a number from such a "dodgy" carrier, and has been allowed by that carrier to associate with it the name of her bank. AFAICT it only helps entities that operate their own identity database, e.g., LEAs and PSAPs. > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > > I may be misunderstanding you, but I think we're kind of getting a solution to that... though maybe not in a way that people want. > > For sake of argument, let's ignore the technology or any proposed solution for STIR, or even STIR in general. Also ignore the existing CNAM business model and pretend we wanted to provide CNAM for the first time, from scratch. > > We know we can't just trust callerid4u to claim any CNAM it wanted to. So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). > > So then we look at how to put this into SIP, and instead of putting the whole certificate in the INVITE, we use an external database lookup mechanism. That's basically STIR, for the phone number part. And the existing CNAM databases are basically the "CA", where they provide a trusted lookup database of phone-number -> CNAM. Since STIR validates the phone number, the CNAM database lookup should be valid... assuming you trust the CNAM database to be valid to begin with. But if you *don't* trust it, it's not clear why you'd trust any other CA either. > > So we already have (or will once we have STIR) a way to get a fairly valid CNAM, if you believe in a CA model for that. What we don't have is a different pricing/business model for how the "CA" charges for retrieving the "certificate" data. But I don't think it's the technology that causes this really, so it's not something we can fix here. I mean even web CAs charge an impressive amount of money for web certificates, and the technology part of the job is trivial for them, afaik. They charge what they believe the market will bear. > > -hadriel > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > >> With respect, I think statements like " I don't see how signing helps " put the cart before the horse. Signing is an attribute of a possible solution, not a requirement. >> >> It is precisely the www.callerid4u.com scenario you note, that worries me. ISTM that if we declare any sort of validation for calling name to be out of scope, we provide no solution to the victims of scams enabled by services that allow dishonest actors to associate the name of a bank with their phone number. >> >> I recognize that names are not delegated in the same way that numbers are, and that there are all sorts of semantic nuances that make their validation difficult. Still, CA's do it. And it's been proposed on this list that a smartphone app could do it. So I don't see why we're so quick to agree we can't do it. Or at least, do something. >> >> I'm a pragmatist. Maybe we can't do as good a job validating names as we can numbers. I still think it's better to make things better than to do nothing. For example ISTM it'd be positive progress to enable the called party to make a more informed decision about whether to trust the calling name, than he can today. >> >> tim >> >> p.s. I tend to agree with Rich, that we can't forever duck the issue of what gets presented to the called party. Whether it's addressed directly or not, we're already making assumptions about what is and isn't reasonable. >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> Just piling on... There are at least three levels of information here, making it difficult to do that within the signaling framework: >> >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured >> bank", "located in Washington, DC", "registered charity") >> >> This is more whois-like information than just the SIP display name. In the certificate space, we have two levels: (1) assertion of domain name control; (2) EV (extended validation) certs. It would be interesting to see how well the EV concept has worked out in practice. >> >> I don't see how signing helps here at all, for the reasons mentioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimate number with just about any name string. And for corporate accounts, the service provider has no way of knowing whether Tom Sawyer is really at a particular number in a range and whether that entity prefers to list the name of the person, just the organization, the location ("PizzaHut Leonia") or something else. Indeed, the same number can legitimately have multiple display names that change quickly over time (e.g., staff at the doctor's office). >> >> Verifiable whois-like information could be very useful and service providers could see that as an opportunity, given that they do know a lot about their customers, such as their billing and service address and how long they have been in business. But it's a separate problem, probably more closely related to the number allocation problem. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>> >>> With TNs, we have credentials that accompany number delegation - we >>> have a clear path to assuring that the caller asserting the identity >>> is indeed entitled to claim control of that number (well, SPs >>> mostly, not the caller, at least initially). There is no equivalent >>> assurance for CNAM. >>> >>> I don't want to get into a fight over which database is better, but >>> the alternate, doesn't depend on the origination carrier mechansism >>> is statisically actually a better "validation" of the content than >>> what a traditional carrier gets in his service order (because they >>> usually don't actually validate the content), and is infiniately >>> better than the carriers that allow the consumer to put anything >>> they want in the database. Without a reasonable way to assure that >>> the database is actually valid, what is the value of carrying an assertion? >> >> While I recognize that letting the customer put in whatever they want >> is problematic, I have no idea whether the alternative of letting the >> CNAM provider include whatever they want is "better". (How would we >> measure >> that?) >> >> (I've just been trying to deal with an "information aggregator" that >> is publishing wrong information about me and won't change it. So I'm >> not feeling good about that sort of thing.) >> >> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good will of the >> people involved, but that have now been automated into monstrosities >> that nobody understands. (Management of healthcare data is another >> example.) >> >> Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws. >> >> Alternatively this could be left to the open market. (E.g., The >> callee could just Google the calling number.) >> >> In any case STIR can't go down this rat hole. >> >> Thanks, >> Paul >> >>> If we had such a mechanism, what prevents one of the carriers that >>> let's you put anything you want in the database from asserting that >>> the content of P-A-ID is valid, when the user is allowed to say >>> whatever they want goes in P-A-ID? >>> >>> The best thing I can come up with would be to have some independent >>> validation service that used other data sources to validate the >>> content, and let them sign it. Then we could carry that signature somewhere. >>> >>> Right now, I think we should leave it out of scope. If we can >>> figure out a way to do validation, then we can revisit the notion of >>> carrying evidence of validation in future work. >>> >>> Does argue for making sure that whatever mechanism we arrive at >>> should have some obvious extension mechanism, perhaps along the >>> lines of what Jon was suggesting for media properties. If you >>> recall, he proposed to have a digest of SDP where the digest was >>> protected by the signature, but if the SDP received didn't match the >>> SDP sent, the termination side could know that, but the basic >>> identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP). >>> >>> Brian >>> >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>> >>> Would it be possible to provide an indication of whether the calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>> >>> __ __ >>> >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>> >>> __ __ >>> >>> tim____ >>> >>> __ __ >>> >>> __ __ >>> >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I assume the concern in this thread is with the case where a number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed to >>> get Bank of America into his CNAM entry.____ >>> >>> __ __ >>> >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least in >>> the case above it should be possible to trace back to the >>> perp.____ >>> >>> __ __ >>> >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number was >>> validated on not - whether calls get blocked or unvalidated numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>> >>> __ __ >>> >>> Penn Pfautz____ >>> >>> AT&T Access Management____ >>> >>> +1-732-420-4962____ >>> >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I think we probably should keep CNAM out of this for now >>> anyway.____ >>> >>> __ __ >>> >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>> >>> __ __ >>> >>> The current CNAM databases cannot be called "authoritative" really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there isn't >>> any attempt to validate those names, and there are carriers who will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>> >>> __ __ >>> >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>> >>> __ __ >>> >>> Brian ____ >>> >>> >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>> >>> >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0045_01CE9A65.4329A460 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx NjEzNDQ1NFowIwYJKoZIhvcNAQkEMRYEFCkqPKsK0SinaU7E6TP80mwuEyVeMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAeLES7NYpmeWNTAliqRmem5aUrmg3Tv41evajTZ9k EvSq3Jkm4ijFMKYIIRnFHU9EAr9MzEsKMh4n5U5VA1W4yJecDj9j97M5sTOAicdV2kiwc4l6yKSF mQiSLMDnjLLaQiXTlOezS6MJxNLlUf5m+v9v90f2t28uIcGblIZA7XTQJOJJ1tkiuLtZmq8DVMBu BcnonVqN5VfSDlSKhyVZeRYUf17fsMTuP35KefQNo0NK7QuIlv6xe7LWtvcwKZ9U6iXr2mtOFyRt mjfs64Q194LRUNydlkwoo9ieW6NDyMc9Q9R1TwuRDZdfA15vZsyKRou8+cq7cNUVMJ+zMvEG1QAA AAAAAA== ------=_NextPart_000_0045_01CE9A65.4329A460-- From timothy.dwight@verizon.com Fri Aug 16 07:13:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A4411E827B for ; Fri, 16 Aug 2013 07:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.935, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TED17VnVGDwL for ; Fri, 16 Aug 2013 07:13:15 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 117E811E8258 for ; Fri, 16 Aug 2013 07:13:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 16 Aug 2013 14:13:11 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,895,1367971200"; d="scan'208";a="528005017" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 16 Aug 2013 14:13:11 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Fri, 16 Aug 2013 10:13:10 -0400 To: Michael Hammer , "hadriel.kaplan@oracle.com" Date: Fri, 16 Aug 2013 10:13:09 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAAwhwCAAGoAgIAAIfKA//+NN+CAAAM74A== Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3D68@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC29963@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC29963@EX2K10MB1.corp.yaanatech.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 14:13:20 -0000 Mike, Please see comments inline, preceded by [tmd]. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 8:45 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) If that "3rd party" is really the 2nd party, i.e. the terminating phone, th= en it might just be trustworthy. [tmd] I guess what you mean is that if the calling number is in your contac= t list you can trust the calling name displayed, because you probably creat= ed the contact list entry yourself. Fair enough. But I doubt that's a sig= nificant use case. Attackers usually claim to be someone like your bank, w= hose number is probably *not* in your contact list. And of course this who= le scenario assumes your phone *has* a contact list, which it may but won't= always. The end user can learn what number to trust based on experience. [tmd] Yes, that occurred to me too. My idea was that even if we can't vali= date the calling name, in the same sense that we validate the calling numbe= r, we could at least inform the called party of who asserted it. Assuming = we had some secure way to do that, the called party could then decide wheth= er he trusts assertions made by that entity. It's far from perfect, but mi= ght be an improvement (if the called party's equipment can make that inform= ation make sense to the human holding the phone). All this discussion is interesting, but it all depends on the input to the = CNAM lookup being accurate, no? [tmd] Not necessarily. If the terminating carrier uses CNAM, then he benef= its from the input being valid. But CNAM isn't the only way to obtain call= ing party name. Regardless, I'm not arguing that validating calling party = number is useless. It's IMHO necessary but not sufficient. It protects la= w enforcement agencies and PSAPs (who have their own identity databases) bu= t it doesn't adequately protect consumers (who don't, except for the contac= t list in their phone). Ensuring that the number is valid is Step 1, what I thought the focus of ST= IR is. All the rest of this is derivative. [tmd] I guess that's what we're discussing. My worry is that if we stop th= ere, we'll be perceived as the latest failure to address the problems exper= ienced by consumers. We may put dent in SWATting but identity theft and ba= nk scams won't be deterred. This sounds to me like a BOF discussion for a follow-on WG. And one that w= e could send all those concerned with privacy to. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Friday, August 16, 2013 9:30 AM To: Hadriel Kaplan Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) The ability to "cross-check" or otherwise validate the contents of a database, is not unique to "3rd parties". It baffles me why involving a 3r= d party would be expected to make things better. AFAICS the service provider and the 3rd party are equally capable of being vigilent with respect to the content of their database; but the service provider is uniquely positioned by virtue of his ongoing business relationship with the calling party. Tha= t relationship gives him greater access to information about the customer's identity, and more incentive to manage it properly, than a 3rd party would have. That doesn't eliminate the potential for "dodgy" service providers. Obviously. But 3rd party database providers have the same potential to be "dodgy", and less incentive not to be. I wish that last comment were true, but I don't think it is. The problem i= s that "dodgy" entities typically interconnect to the PSTN via wholesale services provided by a "traditional" carrier. To exchange traffic with the= m you go through their wholesale provider. Even if A and B directly interconnect, and neither is the least bit "dodgy", there may be sitting behind one or both of them, carriers that are. Even if A and B trust one another completely I think they would still want to be protected from one anothers' wholesale customers. And besides, in business nobody ever trusts anybody completely :-). tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, August 16, 2013 6:29 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) So what that says to me is you can't trust a CA - or at least not all the "CAs". I've been told that some CNAM DB providers don't just blindly believe LIDB entries, but actually perform cross-reference checking with other data. (if they even populated the data from LIDB to begin with) But that's one of the reasons it feels logical to me to keep it in a separate 3rd-party database, because you can't just trust what comes in on SIP/SS7 - you need a third party to perform some verification/cross-checkin= g of the data, and in-advance as opposed to just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call originator and terminator - for that you don't need STIR nor 3rd party CNAM databases) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers can and do run their own LIDBs. As do all sorts of 3rd parties, who get information from God-only-knows where, about individuals with whom they hav= e no business relationship (so, no incentive to "keep happy"). > > Providing a validated calling number would not protect my mom from a scammer who's got a number from such a "dodgy" carrier, and has been allowe= d by that carrier to associate with it the name of her bank. AFAICT it only helps entities that operate their own identity database, e.g., LEAs and PSAPs. > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > > I may be misunderstanding you, but I think we're kind of getting a solution to that... though maybe not in a way that people want. > > For sake of argument, let's ignore the technology or any proposed solutio= n for STIR, or even STIR in general. Also ignore the existing CNAM business model and pretend we wanted to provide CNAM for the first time, from scratch. > > We know we can't just trust callerid4u to claim any CNAM it wanted to. S= o let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). > > So then we look at how to put this into SIP, and instead of putting the whole certificate in the INVITE, we use an external database lookup mechanism. That's basically STIR, for the phone number part. And the existing CNAM databases are basically the "CA", where they provide a truste= d lookup database of phone-number -> CNAM. Since STIR validates the phone number, the CNAM database lookup should be valid... assuming you trust the CNAM database to be valid to begin with. But if you *don't* trust it, it's not clear why you'd trust any other CA either. > > So we already have (or will once we have STIR) a way to get a fairly vali= d CNAM, if you believe in a CA model for that. What we don't have is a different pricing/business model for how the "CA" charges for retrieving th= e "certificate" data. But I don't think it's the technology that causes this really, so it's not something we can fix here. I mean even web CAs charge an impressive amount of money for web certificates, and the technology part of the job is trivial for them, afaik. They charge what they believe the market will bear. > > -hadriel > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > >> With respect, I think statements like " I don't see how signing helps " put the cart before the horse. Signing is an attribute of a possible solution, not a requirement. >> >> It is precisely the www.callerid4u.com scenario you note, that worries me. ISTM that if we declare any sort of validation for calling name to be out of scope, we provide no solution to the victims of scams enabled by services that allow dishonest actors to associate the name of a bank with their phone number. >> >> I recognize that names are not delegated in the same way that numbers are, and that there are all sorts of semantic nuances that make their validation difficult. Still, CA's do it. And it's been proposed on this list that a smartphone app could do it. So I don't see why we're so quick to agree we can't do it. Or at least, do something. >> >> I'm a pragmatist. Maybe we can't do as good a job validating names as w= e can numbers. I still think it's better to make things better than to do nothing. For example ISTM it'd be positive progress to enable the called party to make a more informed decision about whether to trust the calling name, than he can today. >> >> tim >> >> p.s. I tend to agree with Rich, that we can't forever duck the issue of what gets presented to the called party. Whether it's addressed directly o= r not, we're already making assumptions about what is and isn't reasonable. >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> Just piling on... There are at least three levels of information here, making it difficult to do that within the signaling framework: >> >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured >> bank", "located in Washington, DC", "registered charity") >> >> This is more whois-like information than just the SIP display name. In the certificate space, we have two levels: (1) assertion of domain name control; (2) EV (extended validation) certs. It would be interesting to see how well the EV concept has worked out in practice. >> >> I don't see how signing helps here at all, for the reasons mentioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimate number with just about any name string. And for corporate accounts, the service provider has no way of knowing whether Tom Sawyer is really at a particular number in a range and whether that entity prefers to list the name of the person, just the organization, the location ("PizzaHut Leonia") or something else. Indeed, the same number can legitimately have multiple display names that change quickly over time (e.g., staff at the doctor's office). >> >> Verifiable whois-like information could be very useful and service providers could see that as an opportunity, given that they do know a lot about their customers, such as their billing and service address and how long they have been in business. But it's a separate problem, probably more closely related to the number allocation problem. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>> >>> With TNs, we have credentials that accompany number delegation - we >>> have a clear path to assuring that the caller asserting the identity >>> is indeed entitled to claim control of that number (well, SPs >>> mostly, not the caller, at least initially). There is no equivalent >>> assurance for CNAM. >>> >>> I don't want to get into a fight over which database is better, but >>> the alternate, doesn't depend on the origination carrier mechansism >>> is statisically actually a better "validation" of the content than >>> what a traditional carrier gets in his service order (because they >>> usually don't actually validate the content), and is infiniately >>> better than the carriers that allow the consumer to put anything >>> they want in the database. Without a reasonable way to assure that >>> the database is actually valid, what is the value of carrying an assertion? >> >> While I recognize that letting the customer put in whatever they want >> is problematic, I have no idea whether the alternative of letting the >> CNAM provider include whatever they want is "better". (How would we >> measure >> that?) >> >> (I've just been trying to deal with an "information aggregator" that >> is publishing wrong information about me and won't change it. So I'm >> not feeling good about that sort of thing.) >> >> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good will of the >> people involved, but that have now been automated into monstrosities >> that nobody understands. (Management of healthcare data is another >> example.) >> >> Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws. >> >> Alternatively this could be left to the open market. (E.g., The >> callee could just Google the calling number.) >> >> In any case STIR can't go down this rat hole. >> >> Thanks, >> Paul >> >>> If we had such a mechanism, what prevents one of the carriers that >>> let's you put anything you want in the database from asserting that >>> the content of P-A-ID is valid, when the user is allowed to say >>> whatever they want goes in P-A-ID? >>> >>> The best thing I can come up with would be to have some independent >>> validation service that used other data sources to validate the >>> content, and let them sign it. Then we could carry that signature somewhere. >>> >>> Right now, I think we should leave it out of scope. If we can >>> figure out a way to do validation, then we can revisit the notion of >>> carrying evidence of validation in future work. >>> >>> Does argue for making sure that whatever mechanism we arrive at >>> should have some obvious extension mechanism, perhaps along the >>> lines of what Jon was suggesting for media properties. If you >>> recall, he proposed to have a digest of SDP where the digest was >>> protected by the signature, but if the SDP received didn't match the >>> SDP sent, the termination side could know that, but the basic >>> identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP). >>> >>> Brian >>> >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>> >>> Would it be possible to provide an indication of whether the calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>> >>> __ __ >>> >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>> >>> __ __ >>> >>> tim____ >>> >>> __ __ >>> >>> __ __ >>> >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I assume the concern in this thread is with the case where a number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed to >>> get Bank of America into his CNAM entry.____ >>> >>> __ __ >>> >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least in >>> the case above it should be possible to trace back to the >>> perp.____ >>> >>> __ __ >>> >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number was >>> validated on not - whether calls get blocked or unvalidated numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>> >>> __ __ >>> >>> Penn Pfautz____ >>> >>> AT&T Access Management____ >>> >>> +1-732-420-4962____ >>> >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I think we probably should keep CNAM out of this for now >>> anyway.____ >>> >>> __ __ >>> >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>> >>> __ __ >>> >>> The current CNAM databases cannot be called "authoritative" really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there isn't >>> any attempt to validate those names, and there are carriers who will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>> >>> __ __ >>> >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>> >>> __ __ >>> >>> Brian ____ >>> >>> >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>> >>> >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Fri Aug 16 07:37:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9342F11E8140 for ; Fri, 16 Aug 2013 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22VkFxSg0aKg for ; Fri, 16 Aug 2013 07:37:47 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 110AE11E8149 for ; Fri, 16 Aug 2013 07:37:47 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 16 Aug 2013 07:37:43 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAAwhwCAAGoAgIAAIfKA//+NN+CAAAM74IAADNZQ Date: Fri, 16 Aug 2013 14:37:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC299DF@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC29963@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3D68@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3D68@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.101] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0052_01CE9A6C.A251D320" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 14:37:51 -0000 ------=_NextPart_000_0052_01CE9A6C.A251D320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't disagree with anything that has been said. I just don't want to get the cart before the horse. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Friday, August 16, 2013 10:13 AM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) Mike, Please see comments inline, preceded by [tmd]. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 8:45 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) If that "3rd party" is really the 2nd party, i.e. the terminating phone, then it might just be trustworthy. [tmd] I guess what you mean is that if the calling number is in your contact list you can trust the calling name displayed, because you probably created the contact list entry yourself. Fair enough. But I doubt that's a significant use case. Attackers usually claim to be someone like your bank, whose number is probably *not* in your contact list. And of course this whole scenario assumes your phone *has* a contact list, which it may but won't always. The end user can learn what number to trust based on experience. [tmd] Yes, that occurred to me too. My idea was that even if we can't validate the calling name, in the same sense that we validate the calling number, we could at least inform the called party of who asserted it. Assuming we had some secure way to do that, the called party could then decide whether he trusts assertions made by that entity. It's far from perfect, but might be an improvement (if the called party's equipment can make that information make sense to the human holding the phone). All this discussion is interesting, but it all depends on the input to the CNAM lookup being accurate, no? [tmd] Not necessarily. If the terminating carrier uses CNAM, then he benefits from the input being valid. But CNAM isn't the only way to obtain calling party name. Regardless, I'm not arguing that validating calling party number is useless. It's IMHO necessary but not sufficient. It protects law enforcement agencies and PSAPs (who have their own identity databases) but it doesn't adequately protect consumers (who don't, except for the contact list in their phone). Ensuring that the number is valid is Step 1, what I thought the focus of STIR is. All the rest of this is derivative. [tmd] I guess that's what we're discussing. My worry is that if we stop there, we'll be perceived as the latest failure to address the problems experienced by consumers. We may put dent in SWATting but identity theft and bank scams won't be deterred. This sounds to me like a BOF discussion for a follow-on WG. And one that we could send all those concerned with privacy to. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Friday, August 16, 2013 9:30 AM To: Hadriel Kaplan Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) The ability to "cross-check" or otherwise validate the contents of a database, is not unique to "3rd parties". It baffles me why involving a 3rd party would be expected to make things better. AFAICS the service provider and the 3rd party are equally capable of being vigilent with respect to the content of their database; but the service provider is uniquely positioned by virtue of his ongoing business relationship with the calling party. That relationship gives him greater access to information about the customer's identity, and more incentive to manage it properly, than a 3rd party would have. That doesn't eliminate the potential for "dodgy" service providers. Obviously. But 3rd party database providers have the same potential to be "dodgy", and less incentive not to be. I wish that last comment were true, but I don't think it is. The problem is that "dodgy" entities typically interconnect to the PSTN via wholesale services provided by a "traditional" carrier. To exchange traffic with them you go through their wholesale provider. Even if A and B directly interconnect, and neither is the least bit "dodgy", there may be sitting behind one or both of them, carriers that are. Even if A and B trust one another completely I think they would still want to be protected from one anothers' wholesale customers. And besides, in business nobody ever trusts anybody completely :-). tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, August 16, 2013 6:29 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) So what that says to me is you can't trust a CA - or at least not all the "CAs". I've been told that some CNAM DB providers don't just blindly believe LIDB entries, but actually perform cross-reference checking with other data. (if they even populated the data from LIDB to begin with) But that's one of the reasons it feels logical to me to keep it in a separate 3rd-party database, because you can't just trust what comes in on SIP/SS7 - you need a third party to perform some verification/cross-checking of the data, and in-advance as opposed to just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call originator and terminator - for that you don't need STIR nor 3rd party CNAM databases) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers > can and do run their own LIDBs. As do all sorts of 3rd parties, who get information from God-only-knows where, about individuals with whom they have no business relationship (so, no incentive to "keep happy"). > > Providing a validated calling number would not protect my mom from a scammer who's got a number from such a "dodgy" carrier, and has been allowed by that carrier to associate with it the name of her bank. AFAICT it only helps entities that operate their own identity database, e.g., LEAs and PSAPs. > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > > I may be misunderstanding you, but I think we're kind of getting a solution to that... though maybe not in a way that people want. > > For sake of argument, let's ignore the technology or any proposed > solution for STIR, or even STIR in general. Also ignore the existing CNAM business model and pretend we wanted to provide CNAM for the first time, from scratch. > > We know we can't just trust callerid4u to claim any CNAM it wanted to. > So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). > > So then we look at how to put this into SIP, and instead of putting > the whole certificate in the INVITE, we use an external database lookup mechanism. That's basically STIR, for the phone number part. And the existing CNAM databases are basically the "CA", where they provide a trusted lookup database of phone-number -> CNAM. Since STIR validates the phone number, the CNAM database lookup should be valid... assuming you trust the CNAM database to be valid to begin with. But if you *don't* trust it, it's not clear why you'd trust any other CA either. > > So we already have (or will once we have STIR) a way to get a fairly > valid CNAM, if you believe in a CA model for that. What we don't have is a different pricing/business model for how the "CA" charges for retrieving the "certificate" data. But I don't think it's the technology that causes this really, so it's not something we can fix here. I mean even web CAs charge an impressive amount of money for web certificates, and the technology part of the job is trivial for them, afaik. They charge what they believe the market will bear. > > -hadriel > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > >> With respect, I think statements like " I don't see how signing helps " put the cart before the horse. Signing is an attribute of a possible solution, not a requirement. >> >> It is precisely the www.callerid4u.com scenario you note, that >> worries me. ISTM that if we declare any sort of validation for calling name to be out of scope, we provide no solution to the victims of scams enabled by services that allow dishonest actors to associate the name of a bank with their phone number. >> >> I recognize that names are not delegated in the same way that numbers are, and that there are all sorts of semantic nuances that make their validation difficult. Still, CA's do it. And it's been proposed on this list that a smartphone app could do it. So I don't see why we're so quick to agree we can't do it. Or at least, do something. >> >> I'm a pragmatist. Maybe we can't do as good a job validating names >> as we can numbers. I still think it's better to make things better than to do nothing. For example ISTM it'd be positive progress to enable the called party to make a more informed decision about whether to trust the calling name, than he can today. >> >> tim >> >> p.s. I tend to agree with Rich, that we can't forever duck the issue >> of what gets presented to the called party. Whether it's addressed directly or not, we're already making assumptions about what is and isn't reasonable. >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> Just piling on... There are at least three levels of information >> here, making it difficult to do that within the signaling framework: >> >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured >> bank", "located in Washington, DC", "registered charity") >> >> This is more whois-like information than just the SIP display name. >> In the certificate space, we have two levels: (1) assertion of domain name control; (2) EV (extended validation) certs. It would be interesting to see how well the EV concept has worked out in practice. >> >> I don't see how signing helps here at all, for the reasons mentioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimate number with just about any name string. And for corporate accounts, the service provider has no way of knowing whether Tom Sawyer is really at a particular number in a range and whether that entity prefers to list the name of the person, just the organization, the location ("PizzaHut Leonia") or something else. Indeed, the same number can legitimately have multiple display names that change quickly over time (e.g., staff at the doctor's office). >> >> Verifiable whois-like information could be very useful and service providers could see that as an opportunity, given that they do know a lot about their customers, such as their billing and service address and how long they have been in business. But it's a separate problem, probably more closely related to the number allocation problem. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>> >>> With TNs, we have credentials that accompany number delegation - we >>> have a clear path to assuring that the caller asserting the identity >>> is indeed entitled to claim control of that number (well, SPs >>> mostly, not the caller, at least initially). There is no equivalent >>> assurance for CNAM. >>> >>> I don't want to get into a fight over which database is better, but >>> the alternate, doesn't depend on the origination carrier mechansism >>> is statisically actually a better "validation" of the content than >>> what a traditional carrier gets in his service order (because they >>> usually don't actually validate the content), and is infiniately >>> better than the carriers that allow the consumer to put anything >>> they want in the database. Without a reasonable way to assure that >>> the database is actually valid, what is the value of carrying an assertion? >> >> While I recognize that letting the customer put in whatever they want >> is problematic, I have no idea whether the alternative of letting the >> CNAM provider include whatever they want is "better". (How would we >> measure >> that?) >> >> (I've just been trying to deal with an "information aggregator" that >> is publishing wrong information about me and won't change it. So I'm >> not feeling good about that sort of thing.) >> >> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good will of the >> people involved, but that have now been automated into monstrosities >> that nobody understands. (Management of healthcare data is another >> example.) >> >> Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws. >> >> Alternatively this could be left to the open market. (E.g., The >> callee could just Google the calling number.) >> >> In any case STIR can't go down this rat hole. >> >> Thanks, >> Paul >> >>> If we had such a mechanism, what prevents one of the carriers that >>> let's you put anything you want in the database from asserting that >>> the content of P-A-ID is valid, when the user is allowed to say >>> whatever they want goes in P-A-ID? >>> >>> The best thing I can come up with would be to have some independent >>> validation service that used other data sources to validate the >>> content, and let them sign it. Then we could carry that signature somewhere. >>> >>> Right now, I think we should leave it out of scope. If we can >>> figure out a way to do validation, then we can revisit the notion of >>> carrying evidence of validation in future work. >>> >>> Does argue for making sure that whatever mechanism we arrive at >>> should have some obvious extension mechanism, perhaps along the >>> lines of what Jon was suggesting for media properties. If you >>> recall, he proposed to have a digest of SDP where the digest was >>> protected by the signature, but if the SDP received didn't match the >>> SDP sent, the termination side could know that, but the basic >>> identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP). >>> >>> Brian >>> >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>> >>> Would it be possible to provide an indication of whether the calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>> >>> __ __ >>> >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>> >>> __ __ >>> >>> tim____ >>> >>> __ __ >>> >>> __ __ >>> >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I assume the concern in this thread is with the case where a number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed to >>> get Bank of America into his CNAM entry.____ >>> >>> __ __ >>> >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least in >>> the case above it should be possible to trace back to the >>> perp.____ >>> >>> __ __ >>> >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number was >>> validated on not - whether calls get blocked or unvalidated numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>> >>> __ __ >>> >>> Penn Pfautz____ >>> >>> AT&T Access Management____ >>> >>> +1-732-420-4962____ >>> >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I think we probably should keep CNAM out of this for now >>> anyway.____ >>> >>> __ __ >>> >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>> >>> __ __ >>> >>> The current CNAM databases cannot be called "authoritative" really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there isn't >>> any attempt to validate those names, and there are carriers who will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>> >>> __ __ >>> >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>> >>> __ __ >>> >>> Brian ____ >>> >>> >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>> >>> >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0052_01CE9A6C.A251D320 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx NjE0Mzc0MVowIwYJKoZIhvcNAQkEMRYEFHSYSca4UzT0vnKXWAHebD8Xm9qnMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAG4heYWKrXi35I1t5D0InlaDAYcL57c/AbEFLHtce mBe6RAdmLxgmTCRZnngaRTD/4PVzL6DP5pnJsCutLYN7ejs0wgHjSAH+hXKdlGkwdetYCuAdxoNt HAFeEr9Lr9EkfH7OSH7F0ry91zftXNmxOHaVy6woaJb1SREIH4U1mXKrAgrMfAg8oFVvLRMTeDmM JpIp9D2Kc5gf5giUJTJYxTvYWM+ez84KuS9yIYAHujDTq2dKpAT0GTUesgFaMr4Efev2hWc0zoGL TYmd+behzDXqbQ5mEFg9xdOvFF821KnImdBPCJ/K3efMzTwfqA04CqoMlfY1G00d5UN/zKGL/gAA AAAAAA== ------=_NextPart_000_0052_01CE9A6C.A251D320-- From timothy.dwight@verizon.com Fri Aug 16 08:00:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7722021F9C12 for ; Fri, 16 Aug 2013 08:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=1.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcSsofLGgnGd for ; Fri, 16 Aug 2013 08:00:13 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 52FF321F9A72 for ; Fri, 16 Aug 2013 08:00:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 16 Aug 2013 15:00:07 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,895,1367971200"; d="scan'208";a="528043830" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 16 Aug 2013 15:00:07 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Fri, 16 Aug 2013 11:00:06 -0400 To: Hadriel Kaplan Date: Fri, 16 Aug 2013 11:00:05 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: Ac6ahkxXhQKdab9vQZSayonmuAWeKQACLZWw Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3E18@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@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 Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:00:19 -0000 Hadriel, You said in part "The reason a 3rd party helps is because there really is i= ncentive for them to not lie: if they lie, the "good" carriers won't use th= em and they won't be as valuable. Their whole business model depends on th= eir data being accurate." I guess this illustrates why it's dangerous to generalize. In my experienc= e anyway, this is sometimes but not always true. In any mature market ther= e are going to be bottom feeders that compete solely on price. In this par= ticular market there also seem to be entities who "try to be bad", i.e., op= enly advertise the fact that they don't validate the information you provid= e. Just as you should not generalize that all 3rd party database providers= are saints, I should not generalize that they're all sinners. No doubt th= e same applies to service providers. I guess all businesses have an incentive to "keep their customer happy", bu= t if you're a bottom feeder that normally just means keeping the price low = and if your business model is to be the fraudster's friend it means enablin= g / facilitating his mischief. Bottom line, that incentive doesn't necessa= rily lead to the dissemination of accurate information. By either the serv= ice provider or a 3rd party. tim=20 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Friday, August 16, 2013 8:41 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On Aug 16, 2013, at 9:30 AM, "Dwight, Timothy M (Tim)" wrote: > The ability to "cross-check" or otherwise validate the contents of a data= base, is not unique to "3rd parties". It baffles me why involving a 3rd pa= rty would be expected to make things better. AFAICS the service provider a= nd the 3rd party are equally capable of being vigilent with respect to the = content of their database; but the service provider is uniquely positioned = by virtue of his ongoing business relationship with the calling party. Tha= t relationship gives him greater access to information about the customer's= identity, and more incentive to manage it properly, than a 3rd party would= have. >=20 > That doesn't eliminate the potential for "dodgy" service providers. Obvi= ously. But 3rd party database providers have the same potential to be "dod= gy", and less incentive not to be. >=20 > I wish that last comment were true, but I don't think it is. The problem= is that "dodgy" entities typically interconnect to the PSTN via wholesale = services provided by a "traditional" carrier. To exchange traffic with the= m you go through their wholesale provider. Even if A and B directly interc= onnect, and neither is the least bit "dodgy", there may be sitting behind o= ne or both of them, carriers that are. Even if A and B trust one another c= ompletely I think they would still want to be protected from one anothers' = wholesale customers. And besides, in business nobody ever trusts anybody c= ompletely :-). Agreed, that last paragraph is basically the problem we have, even for tele= phone numbers let alone CNAM. We've always known this would eventually hap= pen, once the cost of making phone calls and connecting to the network-of-t= rust got cheap enough. The reason a 3rd party helps is because there reall= y is incentive for them to not lie: if they lie, the "good" carriers won't = use them and they won't be as valuable. Their whole business model depends= on their data being accurate. -hadriel From timothy.dwight@verizon.com Fri Aug 16 08:01:28 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580C211E8281 for ; Fri, 16 Aug 2013 08:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-nF6-IoLg0f for ; Fri, 16 Aug 2013 08:01:20 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 47AE221F9CF7 for ; Fri, 16 Aug 2013 08:01:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 16 Aug 2013 15:01:02 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,895,1367971200"; d="scan'208";a="528045837" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 16 Aug 2013 15:00:57 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Fri, 16 Aug 2013 11:00:55 -0400 To: Michael Hammer , "hadriel.kaplan@oracle.com" Date: Fri, 16 Aug 2013 11:00:54 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAAwhwCAAGoAgIAAIfKA//+NN+CAAAM74IAADNZQgAAAkSA= Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3E1F@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC29963@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3D68@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC299DF@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC299DF@EX2K10MB1.corp.yaanatech.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:01:28 -0000 Sure. But equally, we should not omit the cart. Unless we believe that (a= ) the horse by itself is sufficiently valuable, or (b) someone else will pr= ovide the cart. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 9:38 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) I don't disagree with anything that has been said. I just don't want to get the cart before the horse. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Friday, August 16, 2013 10:13 AM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) Mike, Please see comments inline, preceded by [tmd]. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 8:45 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) If that "3rd party" is really the 2nd party, i.e. the terminating phone, then it might just be trustworthy. [tmd] I guess what you mean is that if the calling number is in your contac= t list you can trust the calling name displayed, because you probably created the contact list entry yourself. Fair enough. But I doubt that's a significant use case. Attackers usually claim to be someone like your bank= , whose number is probably *not* in your contact list. And of course this whole scenario assumes your phone *has* a contact list, which it may but won't always. The end user can learn what number to trust based on experience. [tmd] Yes, that occurred to me too. My idea was that even if we can't validate the calling name, in the same sense that we validate the calling number, we could at least inform the called party of who asserted it. Assuming we had some secure way to do that, the called party could then decide whether he trusts assertions made by that entity. It's far from perfect, but might be an improvement (if the called party's equipment can make that information make sense to the human holding the phone). All this discussion is interesting, but it all depends on the input to the CNAM lookup being accurate, no? [tmd] Not necessarily. If the terminating carrier uses CNAM, then he benefits from the input being valid. But CNAM isn't the only way to obtain calling party name. Regardless, I'm not arguing that validating calling party number is useless. It's IMHO necessary but not sufficient. It protects law enforcement agencies and PSAPs (who have their own identity databases) but it doesn't adequately protect consumers (who don't, except for the contact list in their phone). Ensuring that the number is valid is Step 1, what I thought the focus of STIR is. All the rest of this is derivative. [tmd] I guess that's what we're discussing. My worry is that if we stop there, we'll be perceived as the latest failure to address the problems experienced by consumers. We may put dent in SWATting but identity theft and bank scams won't be deterred. This sounds to me like a BOF discussion for a follow-on WG. And one that w= e could send all those concerned with privacy to. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Friday, August 16, 2013 9:30 AM To: Hadriel Kaplan Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) The ability to "cross-check" or otherwise validate the contents of a database, is not unique to "3rd parties". It baffles me why involving a 3r= d party would be expected to make things better. AFAICS the service provider and the 3rd party are equally capable of being vigilent with respect to the content of their database; but the service provider is uniquely positioned by virtue of his ongoing business relationship with the calling party. Tha= t relationship gives him greater access to information about the customer's identity, and more incentive to manage it properly, than a 3rd party would have. That doesn't eliminate the potential for "dodgy" service providers. Obviously. But 3rd party database providers have the same potential to be "dodgy", and less incentive not to be. I wish that last comment were true, but I don't think it is. The problem i= s that "dodgy" entities typically interconnect to the PSTN via wholesale services provided by a "traditional" carrier. To exchange traffic with the= m you go through their wholesale provider. Even if A and B directly interconnect, and neither is the least bit "dodgy", there may be sitting behind one or both of them, carriers that are. Even if A and B trust one another completely I think they would still want to be protected from one anothers' wholesale customers. And besides, in business nobody ever trusts anybody completely :-). tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, August 16, 2013 6:29 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) So what that says to me is you can't trust a CA - or at least not all the "CAs". I've been told that some CNAM DB providers don't just blindly believe LIDB entries, but actually perform cross-reference checking with other data. (if they even populated the data from LIDB to begin with) But that's one of the reasons it feels logical to me to keep it in a separate 3rd-party database, because you can't just trust what comes in on SIP/SS7 - you need a third party to perform some verification/cross-checkin= g of the data, and in-advance as opposed to just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call originator and terminator - for that you don't need STIR nor 3rd party CNAM databases) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers > can and do run their own LIDBs. As do all sorts of 3rd parties, who get information from God-only-knows where, about individuals with whom they hav= e no business relationship (so, no incentive to "keep happy"). > > Providing a validated calling number would not protect my mom from a scammer who's got a number from such a "dodgy" carrier, and has been allowe= d by that carrier to associate with it the name of her bank. AFAICT it only helps entities that operate their own identity database, e.g., LEAs and PSAPs. > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > > I may be misunderstanding you, but I think we're kind of getting a solution to that... though maybe not in a way that people want. > > For sake of argument, let's ignore the technology or any proposed > solution for STIR, or even STIR in general. Also ignore the existing CNAM business model and pretend we wanted to provide CNAM for the first time, from scratch. > > We know we can't just trust callerid4u to claim any CNAM it wanted to. > So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). > > So then we look at how to put this into SIP, and instead of putting > the whole certificate in the INVITE, we use an external database lookup mechanism. That's basically STIR, for the phone number part. And the existing CNAM databases are basically the "CA", where they provide a truste= d lookup database of phone-number -> CNAM. Since STIR validates the phone number, the CNAM database lookup should be valid... assuming you trust the CNAM database to be valid to begin with. But if you *don't* trust it, it's not clear why you'd trust any other CA either. > > So we already have (or will once we have STIR) a way to get a fairly > valid CNAM, if you believe in a CA model for that. What we don't have is a different pricing/business model for how the "CA" charges for retrieving th= e "certificate" data. But I don't think it's the technology that causes this really, so it's not something we can fix here. I mean even web CAs charge an impressive amount of money for web certificates, and the technology part of the job is trivial for them, afaik. They charge what they believe the market will bear. > > -hadriel > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > >> With respect, I think statements like " I don't see how signing helps " put the cart before the horse. Signing is an attribute of a possible solution, not a requirement. >> >> It is precisely the www.callerid4u.com scenario you note, that >> worries me. ISTM that if we declare any sort of validation for calling name to be out of scope, we provide no solution to the victims of scams enabled by services that allow dishonest actors to associate the name of a bank with their phone number. >> >> I recognize that names are not delegated in the same way that numbers are, and that there are all sorts of semantic nuances that make their validation difficult. Still, CA's do it. And it's been proposed on this list that a smartphone app could do it. So I don't see why we're so quick to agree we can't do it. Or at least, do something. >> >> I'm a pragmatist. Maybe we can't do as good a job validating names >> as we can numbers. I still think it's better to make things better than to do nothing. For example ISTM it'd be positive progress to enable the called party to make a more informed decision about whether to trust the calling name, than he can today. >> >> tim >> >> p.s. I tend to agree with Rich, that we can't forever duck the issue >> of what gets presented to the called party. Whether it's addressed directly o= r not, we're already making assumptions about what is and isn't reasonable. >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> Just piling on... There are at least three levels of information >> here, making it difficult to do that within the signaling framework: >> >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured >> bank", "located in Washington, DC", "registered charity") >> >> This is more whois-like information than just the SIP display name. >> In the certificate space, we have two levels: (1) assertion of domain name control; (2) EV (extended validation) certs. It would be interesting to see how well the EV concept has worked out in practice. >> >> I don't see how signing helps here at all, for the reasons mentioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimate number with just about any name string. And for corporate accounts, the service provider has no way of knowing whether Tom Sawyer is really at a particular number in a range and whether that entity prefers to list the name of the person, just the organization, the location ("PizzaHut Leonia") or something else. Indeed, the same number can legitimately have multiple display names that change quickly over time (e.g., staff at the doctor's office). >> >> Verifiable whois-like information could be very useful and service providers could see that as an opportunity, given that they do know a lot about their customers, such as their billing and service address and how long they have been in business. But it's a separate problem, probably more closely related to the number allocation problem. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>> >>> With TNs, we have credentials that accompany number delegation - we >>> have a clear path to assuring that the caller asserting the identity >>> is indeed entitled to claim control of that number (well, SPs >>> mostly, not the caller, at least initially). There is no equivalent >>> assurance for CNAM. >>> >>> I don't want to get into a fight over which database is better, but >>> the alternate, doesn't depend on the origination carrier mechansism >>> is statisically actually a better "validation" of the content than >>> what a traditional carrier gets in his service order (because they >>> usually don't actually validate the content), and is infiniately >>> better than the carriers that allow the consumer to put anything >>> they want in the database. Without a reasonable way to assure that >>> the database is actually valid, what is the value of carrying an assertion? >> >> While I recognize that letting the customer put in whatever they want >> is problematic, I have no idea whether the alternative of letting the >> CNAM provider include whatever they want is "better". (How would we >> measure >> that?) >> >> (I've just been trying to deal with an "information aggregator" that >> is publishing wrong information about me and won't change it. So I'm >> not feeling good about that sort of thing.) >> >> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good will of the >> people involved, but that have now been automated into monstrosities >> that nobody understands. (Management of healthcare data is another >> example.) >> >> Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws. >> >> Alternatively this could be left to the open market. (E.g., The >> callee could just Google the calling number.) >> >> In any case STIR can't go down this rat hole. >> >> Thanks, >> Paul >> >>> If we had such a mechanism, what prevents one of the carriers that >>> let's you put anything you want in the database from asserting that >>> the content of P-A-ID is valid, when the user is allowed to say >>> whatever they want goes in P-A-ID? >>> >>> The best thing I can come up with would be to have some independent >>> validation service that used other data sources to validate the >>> content, and let them sign it. Then we could carry that signature somewhere. >>> >>> Right now, I think we should leave it out of scope. If we can >>> figure out a way to do validation, then we can revisit the notion of >>> carrying evidence of validation in future work. >>> >>> Does argue for making sure that whatever mechanism we arrive at >>> should have some obvious extension mechanism, perhaps along the >>> lines of what Jon was suggesting for media properties. If you >>> recall, he proposed to have a digest of SDP where the digest was >>> protected by the signature, but if the SDP received didn't match the >>> SDP sent, the termination side could know that, but the basic >>> identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP). >>> >>> Brian >>> >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>> >>> Would it be possible to provide an indication of whether the calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>> >>> __ __ >>> >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>> >>> __ __ >>> >>> tim____ >>> >>> __ __ >>> >>> __ __ >>> >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I assume the concern in this thread is with the case where a number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed to >>> get Bank of America into his CNAM entry.____ >>> >>> __ __ >>> >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least in >>> the case above it should be possible to trace back to the >>> perp.____ >>> >>> __ __ >>> >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number was >>> validated on not - whether calls get blocked or unvalidated numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>> >>> __ __ >>> >>> Penn Pfautz____ >>> >>> AT&T Access Management____ >>> >>> +1-732-420-4962____ >>> >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I think we probably should keep CNAM out of this for now >>> anyway.____ >>> >>> __ __ >>> >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>> >>> __ __ >>> >>> The current CNAM databases cannot be called "authoritative" really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there isn't >>> any attempt to validate those names, and there are carriers who will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>> >>> __ __ >>> >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>> >>> __ __ >>> >>> Brian ____ >>> >>> >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>> >>> >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Fri Aug 16 08:14:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7B11E829F for ; Fri, 16 Aug 2013 08:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX-CjOmbCxwg for ; Fri, 16 Aug 2013 08:14:37 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 818B411E8284 for ; Fri, 16 Aug 2013 08:14:37 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 16 Aug 2013 08:14:35 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAAwhwCAAGoAgIAAIfKA//+NN+CAAAM74IAADNZQgAAAkSCAAAjKsA== Date: Fri, 16 Aug 2013 15:14:34 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC29A5A@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC29963@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3D68@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC299DF@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3E1F@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3E1F@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.101] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006B_01CE9A71.C8FD0490" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:14:41 -0000 ------=_NextPart_000_006B_01CE9A71.C8FD0490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We know there will be carts. There can be many types of carts. Many carts means many bunny-trails and rat-holes to go down. Just don't want to get caught up with the design of chrome bumpers and be stuck with a badly designed engine. I think it is valuable to get the horse (team) right first. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Friday, August 16, 2013 11:01 AM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) Sure. But equally, we should not omit the cart. Unless we believe that (a) the horse by itself is sufficiently valuable, or (b) someone else will provide the cart. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 9:38 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) I don't disagree with anything that has been said. I just don't want to get the cart before the horse. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Friday, August 16, 2013 10:13 AM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) Mike, Please see comments inline, preceded by [tmd]. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 8:45 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) If that "3rd party" is really the 2nd party, i.e. the terminating phone, then it might just be trustworthy. [tmd] I guess what you mean is that if the calling number is in your contact list you can trust the calling name displayed, because you probably created the contact list entry yourself. Fair enough. But I doubt that's a significant use case. Attackers usually claim to be someone like your bank, whose number is probably *not* in your contact list. And of course this whole scenario assumes your phone *has* a contact list, which it may but won't always. The end user can learn what number to trust based on experience. [tmd] Yes, that occurred to me too. My idea was that even if we can't validate the calling name, in the same sense that we validate the calling number, we could at least inform the called party of who asserted it. Assuming we had some secure way to do that, the called party could then decide whether he trusts assertions made by that entity. It's far from perfect, but might be an improvement (if the called party's equipment can make that information make sense to the human holding the phone). All this discussion is interesting, but it all depends on the input to the CNAM lookup being accurate, no? [tmd] Not necessarily. If the terminating carrier uses CNAM, then he benefits from the input being valid. But CNAM isn't the only way to obtain calling party name. Regardless, I'm not arguing that validating calling party number is useless. It's IMHO necessary but not sufficient. It protects law enforcement agencies and PSAPs (who have their own identity databases) but it doesn't adequately protect consumers (who don't, except for the contact list in their phone). Ensuring that the number is valid is Step 1, what I thought the focus of STIR is. All the rest of this is derivative. [tmd] I guess that's what we're discussing. My worry is that if we stop there, we'll be perceived as the latest failure to address the problems experienced by consumers. We may put dent in SWATting but identity theft and bank scams won't be deterred. This sounds to me like a BOF discussion for a follow-on WG. And one that we could send all those concerned with privacy to. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Friday, August 16, 2013 9:30 AM To: Hadriel Kaplan Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) The ability to "cross-check" or otherwise validate the contents of a database, is not unique to "3rd parties". It baffles me why involving a 3rd party would be expected to make things better. AFAICS the service provider and the 3rd party are equally capable of being vigilent with respect to the content of their database; but the service provider is uniquely positioned by virtue of his ongoing business relationship with the calling party. That relationship gives him greater access to information about the customer's identity, and more incentive to manage it properly, than a 3rd party would have. That doesn't eliminate the potential for "dodgy" service providers. Obviously. But 3rd party database providers have the same potential to be "dodgy", and less incentive not to be. I wish that last comment were true, but I don't think it is. The problem is that "dodgy" entities typically interconnect to the PSTN via wholesale services provided by a "traditional" carrier. To exchange traffic with them you go through their wholesale provider. Even if A and B directly interconnect, and neither is the least bit "dodgy", there may be sitting behind one or both of them, carriers that are. Even if A and B trust one another completely I think they would still want to be protected from one anothers' wholesale customers. And besides, in business nobody ever trusts anybody completely :-). tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, August 16, 2013 6:29 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) So what that says to me is you can't trust a CA - or at least not all the "CAs". I've been told that some CNAM DB providers don't just blindly believe LIDB entries, but actually perform cross-reference checking with other data. (if they even populated the data from LIDB to begin with) But that's one of the reasons it feels logical to me to keep it in a separate 3rd-party database, because you can't just trust what comes in on SIP/SS7 - you need a third party to perform some verification/cross-checking of the data, and in-advance as opposed to just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call originator and terminator - for that you don't need STIR nor 3rd party CNAM databases) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers > can and do run their own LIDBs. As do all sorts of 3rd parties, who get information from God-only-knows where, about individuals with whom they have no business relationship (so, no incentive to "keep happy"). > > Providing a validated calling number would not protect my mom from a scammer who's got a number from such a "dodgy" carrier, and has been allowed by that carrier to associate with it the name of her bank. AFAICT it only helps entities that operate their own identity database, e.g., LEAs and PSAPs. > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > > I may be misunderstanding you, but I think we're kind of getting a solution to that... though maybe not in a way that people want. > > For sake of argument, let's ignore the technology or any proposed > solution for STIR, or even STIR in general. Also ignore the existing CNAM business model and pretend we wanted to provide CNAM for the first time, from scratch. > > We know we can't just trust callerid4u to claim any CNAM it wanted to. > So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). > > So then we look at how to put this into SIP, and instead of putting > the whole certificate in the INVITE, we use an external database lookup mechanism. That's basically STIR, for the phone number part. And the existing CNAM databases are basically the "CA", where they provide a trusted lookup database of phone-number -> CNAM. Since STIR validates the phone number, the CNAM database lookup should be valid... assuming you trust the CNAM database to be valid to begin with. But if you *don't* trust it, it's not clear why you'd trust any other CA either. > > So we already have (or will once we have STIR) a way to get a fairly > valid CNAM, if you believe in a CA model for that. What we don't have is a different pricing/business model for how the "CA" charges for retrieving the "certificate" data. But I don't think it's the technology that causes this really, so it's not something we can fix here. I mean even web CAs charge an impressive amount of money for web certificates, and the technology part of the job is trivial for them, afaik. They charge what they believe the market will bear. > > -hadriel > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > >> With respect, I think statements like " I don't see how signing helps " put the cart before the horse. Signing is an attribute of a possible solution, not a requirement. >> >> It is precisely the www.callerid4u.com scenario you note, that >> worries me. ISTM that if we declare any sort of validation for calling name to be out of scope, we provide no solution to the victims of scams enabled by services that allow dishonest actors to associate the name of a bank with their phone number. >> >> I recognize that names are not delegated in the same way that numbers are, and that there are all sorts of semantic nuances that make their validation difficult. Still, CA's do it. And it's been proposed on this list that a smartphone app could do it. So I don't see why we're so quick to agree we can't do it. Or at least, do something. >> >> I'm a pragmatist. Maybe we can't do as good a job validating names >> as we can numbers. I still think it's better to make things better than to do nothing. For example ISTM it'd be positive progress to enable the called party to make a more informed decision about whether to trust the calling name, than he can today. >> >> tim >> >> p.s. I tend to agree with Rich, that we can't forever duck the issue >> of what gets presented to the called party. Whether it's addressed directly or not, we're already making assumptions about what is and isn't reasonable. >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> Just piling on... There are at least three levels of information >> here, making it difficult to do that within the signaling framework: >> >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured >> bank", "located in Washington, DC", "registered charity") >> >> This is more whois-like information than just the SIP display name. >> In the certificate space, we have two levels: (1) assertion of domain name control; (2) EV (extended validation) certs. It would be interesting to see how well the EV concept has worked out in practice. >> >> I don't see how signing helps here at all, for the reasons mentioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimate number with just about any name string. And for corporate accounts, the service provider has no way of knowing whether Tom Sawyer is really at a particular number in a range and whether that entity prefers to list the name of the person, just the organization, the location ("PizzaHut Leonia") or something else. Indeed, the same number can legitimately have multiple display names that change quickly over time (e.g., staff at the doctor's office). >> >> Verifiable whois-like information could be very useful and service providers could see that as an opportunity, given that they do know a lot about their customers, such as their billing and service address and how long they have been in business. But it's a separate problem, probably more closely related to the number allocation problem. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>> >>> With TNs, we have credentials that accompany number delegation - we >>> have a clear path to assuring that the caller asserting the identity >>> is indeed entitled to claim control of that number (well, SPs >>> mostly, not the caller, at least initially). There is no equivalent >>> assurance for CNAM. >>> >>> I don't want to get into a fight over which database is better, but >>> the alternate, doesn't depend on the origination carrier mechansism >>> is statisically actually a better "validation" of the content than >>> what a traditional carrier gets in his service order (because they >>> usually don't actually validate the content), and is infiniately >>> better than the carriers that allow the consumer to put anything >>> they want in the database. Without a reasonable way to assure that >>> the database is actually valid, what is the value of carrying an assertion? >> >> While I recognize that letting the customer put in whatever they want >> is problematic, I have no idea whether the alternative of letting the >> CNAM provider include whatever they want is "better". (How would we >> measure >> that?) >> >> (I've just been trying to deal with an "information aggregator" that >> is publishing wrong information about me and won't change it. So I'm >> not feeling good about that sort of thing.) >> >> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good will of the >> people involved, but that have now been automated into monstrosities >> that nobody understands. (Management of healthcare data is another >> example.) >> >> Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws. >> >> Alternatively this could be left to the open market. (E.g., The >> callee could just Google the calling number.) >> >> In any case STIR can't go down this rat hole. >> >> Thanks, >> Paul >> >>> If we had such a mechanism, what prevents one of the carriers that >>> let's you put anything you want in the database from asserting that >>> the content of P-A-ID is valid, when the user is allowed to say >>> whatever they want goes in P-A-ID? >>> >>> The best thing I can come up with would be to have some independent >>> validation service that used other data sources to validate the >>> content, and let them sign it. Then we could carry that signature somewhere. >>> >>> Right now, I think we should leave it out of scope. If we can >>> figure out a way to do validation, then we can revisit the notion of >>> carrying evidence of validation in future work. >>> >>> Does argue for making sure that whatever mechanism we arrive at >>> should have some obvious extension mechanism, perhaps along the >>> lines of what Jon was suggesting for media properties. If you >>> recall, he proposed to have a digest of SDP where the digest was >>> protected by the signature, but if the SDP received didn't match the >>> SDP sent, the termination side could know that, but the basic >>> identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP). >>> >>> Brian >>> >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>> >>> Would it be possible to provide an indication of whether the calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>> >>> __ __ >>> >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>> >>> __ __ >>> >>> tim____ >>> >>> __ __ >>> >>> __ __ >>> >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I assume the concern in this thread is with the case where a number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed to >>> get Bank of America into his CNAM entry.____ >>> >>> __ __ >>> >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least in >>> the case above it should be possible to trace back to the >>> perp.____ >>> >>> __ __ >>> >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number was >>> validated on not - whether calls get blocked or unvalidated numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>> >>> __ __ >>> >>> Penn Pfautz____ >>> >>> AT&T Access Management____ >>> >>> +1-732-420-4962____ >>> >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I think we probably should keep CNAM out of this for now >>> anyway.____ >>> >>> __ __ >>> >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>> >>> __ __ >>> >>> The current CNAM databases cannot be called "authoritative" really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there isn't >>> any attempt to validate those names, and there are carriers who will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>> >>> __ __ >>> >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>> >>> __ __ >>> >>> Brian ____ >>> >>> >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>> >>> >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_006B_01CE9A71.C8FD0490 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx NjE1MTQzM1owIwYJKoZIhvcNAQkEMRYEFJ5KynWdOwhGmIpsJwQc3ib/A/APMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAC3+3hzopJHlL2Z9uyyCL0J75h0a3/JLsgmbDkHxE lGjYPbW4FKK/pTWTV/7KJT4/TDKLajcLZ6UqVp1dEmDPIgsZzwhG9O29RqzQf6dCAUJy4T+/BL76 m79K1P2hHuLifHVpjQgjd78bFxs5KNnShCxsGGWXMtJxO7b6BobTUpVlELwbjp/KMjuhSY/uqQe+ TYm5uy4LTuFEs/4vvnFRet5AkgCJt+XKQQanMlzWQUfnPZ4TvX9Ew4estVcNmZ1uUd6aKjEhYcA+ zkQyqKu+Ws6CNnVmo+27fON43QUBmYO2uydB2P0hp2/nh+NZe1ULxMTw8y3cli20Ytbc+7Z9MQAA AAAAAA== ------=_NextPart_000_006B_01CE9A71.C8FD0490-- From timothy.dwight@verizon.com Fri Aug 16 08:44:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7255A11E8119 for ; Fri, 16 Aug 2013 08:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jEwDB4oX1gt for ; Fri, 16 Aug 2013 08:44:42 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 034E911E8149 for ; Fri, 16 Aug 2013 08:44:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe02.verizonbusiness.com with ESMTP; 16 Aug 2013 15:44:38 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,895,1367971200"; d="scan'208";a="528081235" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 16 Aug 2013 15:44:35 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.250]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Fri, 16 Aug 2013 11:44:35 -0400 To: Michael Hammer , "hadriel.kaplan@oracle.com" Date: Fri, 16 Aug 2013 11:44:34 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAAwhwCAAGoAgIAAIfKA//+NN+CAAAM74IAADNZQgAAAkSCAAAjKsIAAA3Fg Message-ID: <2B0F677F0B95454297753F58D4A07FA3012ADB3E94@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC29963@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3D68@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC299DF@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3E1F@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC29A5A@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC29A5A@EX2K10MB1.corp.yaanatech.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:44:47 -0000 Mike, I understand. It's a good discussion and in the end will be a judgment cal= l. On the one extreme we could attempt to boil the ocean and get nowhere. = On the other extreme we could solve too small a part of the problem to be = relevant, and/or create a partial solution that isn't consistent with the r= equirements of a complete solution (or worse, by its existence, constrains = the set of solutions we will consider for the complete solution). By analo= gy we could design a horse incapable of pulling the cart we later realize n= eeds to be pulled. Maybe the cart turns out to be big and we designed a Sh= etland pony :-). Given that we've spent all that effort designing our pony= , the natural temptation will be to design a cart that such a pony can pull= . To me this is similar to the in-band vs. out-of-band debate. In that case = we decided (I think) that we would focus on the former (to avoid ocean-boil= ing) while "keeping the latter in mind" (to avoid the horse-that-can't-pull= -the-cart scenario). Which seems like a reasonable compromise. Maybe that's what we'll decide to do with calling-name validation too. Fra= nkly I started this discussion thinking that that's as much as I'd get... I= just asked for some "hooks" in the initial solution that would allow us (o= r someone) to extend it. But I know that the difference between agreeing t= o such incorporate such extensibility hooks and boiling the ocean, is a sli= ppery slope. How do you know your extensibility hook will actually be usef= ul? By analogy, how do you know your yoke will be sufficient to pull the c= art without designing the cart? If this resolves to a similar "keep it in mind but don't explicitly work on= it" compromise, and we are willing to be explicit with our "user community= " (suppliers who have to build this stuff and carriers who have to deploy i= t) about what portion of the problem we've addressed, I think I can live wi= th that. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 10:15 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) We know there will be carts. There can be many types of carts. Many carts means many bunny-trails and rat-holes to go down. Just don't want to get caught up with the design of chrome bumpers and be stuck with a badly designed engine. I think it is valuable to get the horse (team) right first. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Friday, August 16, 2013 11:01 AM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) Sure. But equally, we should not omit the cart. Unless we believe that (a= ) the horse by itself is sufficiently valuable, or (b) someone else will provide the cart. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 9:38 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) I don't disagree with anything that has been said. I just don't want to get the cart before the horse. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Friday, August 16, 2013 10:13 AM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) Mike, Please see comments inline, preceded by [tmd]. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 8:45 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) If that "3rd party" is really the 2nd party, i.e. the terminating phone, then it might just be trustworthy. [tmd] I guess what you mean is that if the calling number is in your contac= t list you can trust the calling name displayed, because you probably created the contact list entry yourself. Fair enough. But I doubt that's a significant use case. Attackers usually claim to be someone like your bank= , whose number is probably *not* in your contact list. And of course this whole scenario assumes your phone *has* a contact list, which it may but won't always. The end user can learn what number to trust based on experience. [tmd] Yes, that occurred to me too. My idea was that even if we can't validate the calling name, in the same sense that we validate the calling number, we could at least inform the called party of who asserted it. Assuming we had some secure way to do that, the called party could then decide whether he trusts assertions made by that entity. It's far from perfect, but might be an improvement (if the called party's equipment can make that information make sense to the human holding the phone). All this discussion is interesting, but it all depends on the input to the CNAM lookup being accurate, no? [tmd] Not necessarily. If the terminating carrier uses CNAM, then he benefits from the input being valid. But CNAM isn't the only way to obtain calling party name. Regardless, I'm not arguing that validating calling party number is useless. It's IMHO necessary but not sufficient. It protects law enforcement agencies and PSAPs (who have their own identity databases) but it doesn't adequately protect consumers (who don't, except for the contact list in their phone). Ensuring that the number is valid is Step 1, what I thought the focus of STIR is. All the rest of this is derivative. [tmd] I guess that's what we're discussing. My worry is that if we stop there, we'll be perceived as the latest failure to address the problems experienced by consumers. We may put dent in SWATting but identity theft and bank scams won't be deterred. This sounds to me like a BOF discussion for a follow-on WG. And one that w= e could send all those concerned with privacy to. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Friday, August 16, 2013 9:30 AM To: Hadriel Kaplan Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) The ability to "cross-check" or otherwise validate the contents of a database, is not unique to "3rd parties". It baffles me why involving a 3r= d party would be expected to make things better. AFAICS the service provider and the 3rd party are equally capable of being vigilent with respect to the content of their database; but the service provider is uniquely positioned by virtue of his ongoing business relationship with the calling party. Tha= t relationship gives him greater access to information about the customer's identity, and more incentive to manage it properly, than a 3rd party would have. That doesn't eliminate the potential for "dodgy" service providers. Obviously. But 3rd party database providers have the same potential to be "dodgy", and less incentive not to be. I wish that last comment were true, but I don't think it is. The problem i= s that "dodgy" entities typically interconnect to the PSTN via wholesale services provided by a "traditional" carrier. To exchange traffic with the= m you go through their wholesale provider. Even if A and B directly interconnect, and neither is the least bit "dodgy", there may be sitting behind one or both of them, carriers that are. Even if A and B trust one another completely I think they would still want to be protected from one anothers' wholesale customers. And besides, in business nobody ever trusts anybody completely :-). tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, August 16, 2013 6:29 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) So what that says to me is you can't trust a CA - or at least not all the "CAs". I've been told that some CNAM DB providers don't just blindly believe LIDB entries, but actually perform cross-reference checking with other data. (if they even populated the data from LIDB to begin with) But that's one of the reasons it feels logical to me to keep it in a separate 3rd-party database, because you can't just trust what comes in on SIP/SS7 - you need a third party to perform some verification/cross-checkin= g of the data, and in-advance as opposed to just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call originator and terminator - for that you don't need STIR nor 3rd party CNAM databases) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers > can and do run their own LIDBs. As do all sorts of 3rd parties, who get information from God-only-knows where, about individuals with whom they hav= e no business relationship (so, no incentive to "keep happy"). > > Providing a validated calling number would not protect my mom from a scammer who's got a number from such a "dodgy" carrier, and has been allowe= d by that carrier to associate with it the name of her bank. AFAICT it only helps entities that operate their own identity database, e.g., LEAs and PSAPs. > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > > I may be misunderstanding you, but I think we're kind of getting a solution to that... though maybe not in a way that people want. > > For sake of argument, let's ignore the technology or any proposed > solution for STIR, or even STIR in general. Also ignore the existing CNAM business model and pretend we wanted to provide CNAM for the first time, from scratch. > > We know we can't just trust callerid4u to claim any CNAM it wanted to. > So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). > > So then we look at how to put this into SIP, and instead of putting > the whole certificate in the INVITE, we use an external database lookup mechanism. That's basically STIR, for the phone number part. And the existing CNAM databases are basically the "CA", where they provide a truste= d lookup database of phone-number -> CNAM. Since STIR validates the phone number, the CNAM database lookup should be valid... assuming you trust the CNAM database to be valid to begin with. But if you *don't* trust it, it's not clear why you'd trust any other CA either. > > So we already have (or will once we have STIR) a way to get a fairly > valid CNAM, if you believe in a CA model for that. What we don't have is a different pricing/business model for how the "CA" charges for retrieving th= e "certificate" data. But I don't think it's the technology that causes this really, so it's not something we can fix here. I mean even web CAs charge an impressive amount of money for web certificates, and the technology part of the job is trivial for them, afaik. They charge what they believe the market will bear. > > -hadriel > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > >> With respect, I think statements like " I don't see how signing helps " put the cart before the horse. Signing is an attribute of a possible solution, not a requirement. >> >> It is precisely the www.callerid4u.com scenario you note, that >> worries me. ISTM that if we declare any sort of validation for calling name to be out of scope, we provide no solution to the victims of scams enabled by services that allow dishonest actors to associate the name of a bank with their phone number. >> >> I recognize that names are not delegated in the same way that numbers are, and that there are all sorts of semantic nuances that make their validation difficult. Still, CA's do it. And it's been proposed on this list that a smartphone app could do it. So I don't see why we're so quick to agree we can't do it. Or at least, do something. >> >> I'm a pragmatist. Maybe we can't do as good a job validating names >> as we can numbers. I still think it's better to make things better than to do nothing. For example ISTM it'd be positive progress to enable the called party to make a more informed decision about whether to trust the calling name, than he can today. >> >> tim >> >> p.s. I tend to agree with Rich, that we can't forever duck the issue >> of what gets presented to the called party. Whether it's addressed directly o= r not, we're already making assumptions about what is and isn't reasonable. >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> Just piling on... There are at least three levels of information >> here, making it difficult to do that within the signaling framework: >> >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured >> bank", "located in Washington, DC", "registered charity") >> >> This is more whois-like information than just the SIP display name. >> In the certificate space, we have two levels: (1) assertion of domain name control; (2) EV (extended validation) certs. It would be interesting to see how well the EV concept has worked out in practice. >> >> I don't see how signing helps here at all, for the reasons mentioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimate number with just about any name string. And for corporate accounts, the service provider has no way of knowing whether Tom Sawyer is really at a particular number in a range and whether that entity prefers to list the name of the person, just the organization, the location ("PizzaHut Leonia") or something else. Indeed, the same number can legitimately have multiple display names that change quickly over time (e.g., staff at the doctor's office). >> >> Verifiable whois-like information could be very useful and service providers could see that as an opportunity, given that they do know a lot about their customers, such as their billing and service address and how long they have been in business. But it's a separate problem, probably more closely related to the number allocation problem. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>> >>> With TNs, we have credentials that accompany number delegation - we >>> have a clear path to assuring that the caller asserting the identity >>> is indeed entitled to claim control of that number (well, SPs >>> mostly, not the caller, at least initially). There is no equivalent >>> assurance for CNAM. >>> >>> I don't want to get into a fight over which database is better, but >>> the alternate, doesn't depend on the origination carrier mechansism >>> is statisically actually a better "validation" of the content than >>> what a traditional carrier gets in his service order (because they >>> usually don't actually validate the content), and is infiniately >>> better than the carriers that allow the consumer to put anything >>> they want in the database. Without a reasonable way to assure that >>> the database is actually valid, what is the value of carrying an assertion? >> >> While I recognize that letting the customer put in whatever they want >> is problematic, I have no idea whether the alternative of letting the >> CNAM provider include whatever they want is "better". (How would we >> measure >> that?) >> >> (I've just been trying to deal with an "information aggregator" that >> is publishing wrong information about me and won't change it. So I'm >> not feeling good about that sort of thing.) >> >> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good will of the >> people involved, but that have now been automated into monstrosities >> that nobody understands. (Management of healthcare data is another >> example.) >> >> Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws. >> >> Alternatively this could be left to the open market. (E.g., The >> callee could just Google the calling number.) >> >> In any case STIR can't go down this rat hole. >> >> Thanks, >> Paul >> >>> If we had such a mechanism, what prevents one of the carriers that >>> let's you put anything you want in the database from asserting that >>> the content of P-A-ID is valid, when the user is allowed to say >>> whatever they want goes in P-A-ID? >>> >>> The best thing I can come up with would be to have some independent >>> validation service that used other data sources to validate the >>> content, and let them sign it. Then we could carry that signature somewhere. >>> >>> Right now, I think we should leave it out of scope. If we can >>> figure out a way to do validation, then we can revisit the notion of >>> carrying evidence of validation in future work. >>> >>> Does argue for making sure that whatever mechanism we arrive at >>> should have some obvious extension mechanism, perhaps along the >>> lines of what Jon was suggesting for media properties. If you >>> recall, he proposed to have a digest of SDP where the digest was >>> protected by the signature, but if the SDP received didn't match the >>> SDP sent, the termination side could know that, but the basic >>> identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP). >>> >>> Brian >>> >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>> >>> Would it be possible to provide an indication of whether the calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>> >>> __ __ >>> >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>> >>> __ __ >>> >>> tim____ >>> >>> __ __ >>> >>> __ __ >>> >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I assume the concern in this thread is with the case where a number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed to >>> get Bank of America into his CNAM entry.____ >>> >>> __ __ >>> >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least in >>> the case above it should be possible to trace back to the >>> perp.____ >>> >>> __ __ >>> >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number was >>> validated on not - whether calls get blocked or unvalidated numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>> >>> __ __ >>> >>> Penn Pfautz____ >>> >>> AT&T Access Management____ >>> >>> +1-732-420-4962____ >>> >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I think we probably should keep CNAM out of this for now >>> anyway.____ >>> >>> __ __ >>> >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>> >>> __ __ >>> >>> The current CNAM databases cannot be called "authoritative" really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there isn't >>> any attempt to validate those names, and there are carriers who will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>> >>> __ __ >>> >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>> >>> __ __ >>> >>> Brian ____ >>> >>> >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>> >>> >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Fri Aug 16 08:58:54 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C52B11E82A4 for ; Fri, 16 Aug 2013 08:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0hEcJoABEd2 for ; Fri, 16 Aug 2013 08:58:50 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5717611E8168 for ; Fri, 16 Aug 2013 08:58:50 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 16 Aug 2013 08:58:48 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAAwhwCAAGoAgIAAIfKA//+NN+CAAAM74IAADNZQgAAAkSCAAAjKsIAAA3FggAAJALA= Date: Fri, 16 Aug 2013 15:58:47 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC29AC2@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC29963@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3D68@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC299DF@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3E1F@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC29A5A@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3E94@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3E94@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.101] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007C_01CE9A77.F6082E00" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:58:54 -0000 ------=_NextPart_000_007C_01CE9A77.F6082E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Understand. I would like to request that we don't end up designing it so that the horse can only be used with one cart type. i.e. keep it loosely coupled. I am not so worried that if we get this one basic function right, it won't get incorporated in many higher-level features. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Friday, August 16, 2013 11:45 AM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) Mike, I understand. It's a good discussion and in the end will be a judgment call. On the one extreme we could attempt to boil the ocean and get nowhere. On the other extreme we could solve too small a part of the problem to be relevant, and/or create a partial solution that isn't consistent with the requirements of a complete solution (or worse, by its existence, constrains the set of solutions we will consider for the complete solution). By analogy we could design a horse incapable of pulling the cart we later realize needs to be pulled. Maybe the cart turns out to be big and we designed a Shetland pony :-). Given that we've spent all that effort designing our pony, the natural temptation will be to design a cart that such a pony can pull. To me this is similar to the in-band vs. out-of-band debate. In that case we decided (I think) that we would focus on the former (to avoid ocean-boiling) while "keeping the latter in mind" (to avoid the horse-that-can't-pull-the-cart scenario). Which seems like a reasonable compromise. Maybe that's what we'll decide to do with calling-name validation too. Frankly I started this discussion thinking that that's as much as I'd get... I just asked for some "hooks" in the initial solution that would allow us (or someone) to extend it. But I know that the difference between agreeing to such incorporate such extensibility hooks and boiling the ocean, is a slippery slope. How do you know your extensibility hook will actually be useful? By analogy, how do you know your yoke will be sufficient to pull the cart without designing the cart? If this resolves to a similar "keep it in mind but don't explicitly work on it" compromise, and we are willing to be explicit with our "user community" (suppliers who have to build this stuff and carriers who have to deploy it) about what portion of the problem we've addressed, I think I can live with that. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 10:15 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) We know there will be carts. There can be many types of carts. Many carts means many bunny-trails and rat-holes to go down. Just don't want to get caught up with the design of chrome bumpers and be stuck with a badly designed engine. I think it is valuable to get the horse (team) right first. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Friday, August 16, 2013 11:01 AM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) Sure. But equally, we should not omit the cart. Unless we believe that (a) the horse by itself is sufficiently valuable, or (b) someone else will provide the cart. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 9:38 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) I don't disagree with anything that has been said. I just don't want to get the cart before the horse. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Friday, August 16, 2013 10:13 AM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) Mike, Please see comments inline, preceded by [tmd]. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, August 16, 2013 8:45 AM To: Dwight, Timothy M (Tim); hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter) If that "3rd party" is really the 2nd party, i.e. the terminating phone, then it might just be trustworthy. [tmd] I guess what you mean is that if the calling number is in your contact list you can trust the calling name displayed, because you probably created the contact list entry yourself. Fair enough. But I doubt that's a significant use case. Attackers usually claim to be someone like your bank, whose number is probably *not* in your contact list. And of course this whole scenario assumes your phone *has* a contact list, which it may but won't always. The end user can learn what number to trust based on experience. [tmd] Yes, that occurred to me too. My idea was that even if we can't validate the calling name, in the same sense that we validate the calling number, we could at least inform the called party of who asserted it. Assuming we had some secure way to do that, the called party could then decide whether he trusts assertions made by that entity. It's far from perfect, but might be an improvement (if the called party's equipment can make that information make sense to the human holding the phone). All this discussion is interesting, but it all depends on the input to the CNAM lookup being accurate, no? [tmd] Not necessarily. If the terminating carrier uses CNAM, then he benefits from the input being valid. But CNAM isn't the only way to obtain calling party name. Regardless, I'm not arguing that validating calling party number is useless. It's IMHO necessary but not sufficient. It protects law enforcement agencies and PSAPs (who have their own identity databases) but it doesn't adequately protect consumers (who don't, except for the contact list in their phone). Ensuring that the number is valid is Step 1, what I thought the focus of STIR is. All the rest of this is derivative. [tmd] I guess that's what we're discussing. My worry is that if we stop there, we'll be perceived as the latest failure to address the problems experienced by consumers. We may put dent in SWATting but identity theft and bank scams won't be deterred. This sounds to me like a BOF discussion for a follow-on WG. And one that we could send all those concerned with privacy to. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Friday, August 16, 2013 9:30 AM To: Hadriel Kaplan Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) The ability to "cross-check" or otherwise validate the contents of a database, is not unique to "3rd parties". It baffles me why involving a 3rd party would be expected to make things better. AFAICS the service provider and the 3rd party are equally capable of being vigilent with respect to the content of their database; but the service provider is uniquely positioned by virtue of his ongoing business relationship with the calling party. That relationship gives him greater access to information about the customer's identity, and more incentive to manage it properly, than a 3rd party would have. That doesn't eliminate the potential for "dodgy" service providers. Obviously. But 3rd party database providers have the same potential to be "dodgy", and less incentive not to be. I wish that last comment were true, but I don't think it is. The problem is that "dodgy" entities typically interconnect to the PSTN via wholesale services provided by a "traditional" carrier. To exchange traffic with them you go through their wholesale provider. Even if A and B directly interconnect, and neither is the least bit "dodgy", there may be sitting behind one or both of them, carriers that are. Even if A and B trust one another completely I think they would still want to be protected from one anothers' wholesale customers. And besides, in business nobody ever trusts anybody completely :-). tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, August 16, 2013 6:29 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) So what that says to me is you can't trust a CA - or at least not all the "CAs". I've been told that some CNAM DB providers don't just blindly believe LIDB entries, but actually perform cross-reference checking with other data. (if they even populated the data from LIDB to begin with) But that's one of the reasons it feels logical to me to keep it in a separate 3rd-party database, because you can't just trust what comes in on SIP/SS7 - you need a third party to perform some verification/cross-checking of the data, and in-advance as opposed to just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call originator and terminator - for that you don't need STIR nor 3rd party CNAM databases) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers > can and do run their own LIDBs. As do all sorts of 3rd parties, who get information from God-only-knows where, about individuals with whom they have no business relationship (so, no incentive to "keep happy"). > > Providing a validated calling number would not protect my mom from a scammer who's got a number from such a "dodgy" carrier, and has been allowed by that carrier to associate with it the name of her bank. AFAICT it only helps entities that operate their own identity database, e.g., LEAs and PSAPs. > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > > I may be misunderstanding you, but I think we're kind of getting a solution to that... though maybe not in a way that people want. > > For sake of argument, let's ignore the technology or any proposed > solution for STIR, or even STIR in general. Also ignore the existing CNAM business model and pretend we wanted to provide CNAM for the first time, from scratch. > > We know we can't just trust callerid4u to claim any CNAM it wanted to. > So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). > > So then we look at how to put this into SIP, and instead of putting > the whole certificate in the INVITE, we use an external database lookup mechanism. That's basically STIR, for the phone number part. And the existing CNAM databases are basically the "CA", where they provide a trusted lookup database of phone-number -> CNAM. Since STIR validates the phone number, the CNAM database lookup should be valid... assuming you trust the CNAM database to be valid to begin with. But if you *don't* trust it, it's not clear why you'd trust any other CA either. > > So we already have (or will once we have STIR) a way to get a fairly > valid CNAM, if you believe in a CA model for that. What we don't have is a different pricing/business model for how the "CA" charges for retrieving the "certificate" data. But I don't think it's the technology that causes this really, so it's not something we can fix here. I mean even web CAs charge an impressive amount of money for web certificates, and the technology part of the job is trivial for them, afaik. They charge what they believe the market will bear. > > -hadriel > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > >> With respect, I think statements like " I don't see how signing helps " put the cart before the horse. Signing is an attribute of a possible solution, not a requirement. >> >> It is precisely the www.callerid4u.com scenario you note, that >> worries me. ISTM that if we declare any sort of validation for calling name to be out of scope, we provide no solution to the victims of scams enabled by services that allow dishonest actors to associate the name of a bank with their phone number. >> >> I recognize that names are not delegated in the same way that numbers are, and that there are all sorts of semantic nuances that make their validation difficult. Still, CA's do it. And it's been proposed on this list that a smartphone app could do it. So I don't see why we're so quick to agree we can't do it. Or at least, do something. >> >> I'm a pragmatist. Maybe we can't do as good a job validating names >> as we can numbers. I still think it's better to make things better than to do nothing. For example ISTM it'd be positive progress to enable the called party to make a more informed decision about whether to trust the calling name, than he can today. >> >> tim >> >> p.s. I tend to agree with Rich, that we can't forever duck the issue >> of what gets presented to the called party. Whether it's addressed directly or not, we're already making assumptions about what is and isn't reasonable. >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> Just piling on... There are at least three levels of information >> here, making it difficult to do that within the signaling framework: >> >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured >> bank", "located in Washington, DC", "registered charity") >> >> This is more whois-like information than just the SIP display name. >> In the certificate space, we have two levels: (1) assertion of domain name control; (2) EV (extended validation) certs. It would be interesting to see how well the EV concept has worked out in practice. >> >> I don't see how signing helps here at all, for the reasons mentioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimate number with just about any name string. And for corporate accounts, the service provider has no way of knowing whether Tom Sawyer is really at a particular number in a range and whether that entity prefers to list the name of the person, just the organization, the location ("PizzaHut Leonia") or something else. Indeed, the same number can legitimately have multiple display names that change quickly over time (e.g., staff at the doctor's office). >> >> Verifiable whois-like information could be very useful and service providers could see that as an opportunity, given that they do know a lot about their customers, such as their billing and service address and how long they have been in business. But it's a separate problem, probably more closely related to the number allocation problem. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>> >>> With TNs, we have credentials that accompany number delegation - we >>> have a clear path to assuring that the caller asserting the identity >>> is indeed entitled to claim control of that number (well, SPs >>> mostly, not the caller, at least initially). There is no equivalent >>> assurance for CNAM. >>> >>> I don't want to get into a fight over which database is better, but >>> the alternate, doesn't depend on the origination carrier mechansism >>> is statisically actually a better "validation" of the content than >>> what a traditional carrier gets in his service order (because they >>> usually don't actually validate the content), and is infiniately >>> better than the carriers that allow the consumer to put anything >>> they want in the database. Without a reasonable way to assure that >>> the database is actually valid, what is the value of carrying an assertion? >> >> While I recognize that letting the customer put in whatever they want >> is problematic, I have no idea whether the alternative of letting the >> CNAM provider include whatever they want is "better". (How would we >> measure >> that?) >> >> (I've just been trying to deal with an "information aggregator" that >> is publishing wrong information about me and won't change it. So I'm >> not feeling good about that sort of thing.) >> >> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good will of the >> people involved, but that have now been automated into monstrosities >> that nobody understands. (Management of healthcare data is another >> example.) >> >> Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws. >> >> Alternatively this could be left to the open market. (E.g., The >> callee could just Google the calling number.) >> >> In any case STIR can't go down this rat hole. >> >> Thanks, >> Paul >> >>> If we had such a mechanism, what prevents one of the carriers that >>> let's you put anything you want in the database from asserting that >>> the content of P-A-ID is valid, when the user is allowed to say >>> whatever they want goes in P-A-ID? >>> >>> The best thing I can come up with would be to have some independent >>> validation service that used other data sources to validate the >>> content, and let them sign it. Then we could carry that signature somewhere. >>> >>> Right now, I think we should leave it out of scope. If we can >>> figure out a way to do validation, then we can revisit the notion of >>> carrying evidence of validation in future work. >>> >>> Does argue for making sure that whatever mechanism we arrive at >>> should have some obvious extension mechanism, perhaps along the >>> lines of what Jon was suggesting for media properties. If you >>> recall, he proposed to have a digest of SDP where the digest was >>> protected by the signature, but if the SDP received didn't match the >>> SDP sent, the termination side could know that, but the basic >>> identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP). >>> >>> Brian >>> >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>> >>> Would it be possible to provide an indication of whether the calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>> >>> __ __ >>> >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>> >>> __ __ >>> >>> tim____ >>> >>> __ __ >>> >>> __ __ >>> >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I assume the concern in this thread is with the case where a number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed to >>> get Bank of America into his CNAM entry.____ >>> >>> __ __ >>> >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least in >>> the case above it should be possible to trace back to the >>> perp.____ >>> >>> __ __ >>> >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number was >>> validated on not - whether calls get blocked or unvalidated numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>> >>> __ __ >>> >>> Penn Pfautz____ >>> >>> AT&T Access Management____ >>> >>> +1-732-420-4962____ >>> >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I think we probably should keep CNAM out of this for now >>> anyway.____ >>> >>> __ __ >>> >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>> >>> __ __ >>> >>> The current CNAM databases cannot be called "authoritative" really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there isn't >>> any attempt to validate those names, and there are carriers who will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>> >>> __ __ >>> >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>> >>> __ __ >>> >>> Brian ____ >>> >>> >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>> >>> >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_007C_01CE9A77.F6082E00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx NjE1NTg0NVowIwYJKoZIhvcNAQkEMRYEFPlpVbb9zpI7B9X/MNwkG3u9kG8pMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAZruj/UtqJh5kPH7rNZwBYFUFnx4uc6syt/m2cwD7 ImGMdPHU/xzcLIAcQROsNMiWZHSNbLJelewxRoyKiU75/BvB3JxY95l/6ZLd2wI0pUAn0OT5OXQI rjJNYY2jl/8laAvFMQN6bwk+00viwmDab9xPzjVHH7l4Dio6FFaI3dXhRMgfGYNTFck254yIWHEa kKrx9OgSqmNnpkiOi02RVVmAi+Mr+xl9Qs5cJR7x5AI/oDUjHJwiryZ87gSyJALr68082OYFgEpF e10HuPed6s9yZTuHKHN9wp6iaoIQYG63e+hWsaYX1QzI+Fjg+ID8hQlUPo7ks+JZrjnHHNrXXAAA AAAAAA== ------=_NextPart_000_007C_01CE9A77.F6082E00-- From fas_vm@surguttel.ru Mon Aug 19 06:01:10 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA8B21F996F for ; Mon, 19 Aug 2013 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.722 X-Spam-Level: * X-Spam-Status: No, score=1.722 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWl6T6GbuK3n for ; Mon, 19 Aug 2013 06:01:03 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id D12DE21F9B19 for ; Mon, 19 Aug 2013 06:01:02 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id C67615143BE; Mon, 19 Aug 2013 19:00:59 +0600 (YEKT) Received: from Gateway (unknown [151.252.74.56]) by mail.s86.ru (Postfix) with ESMTPA id 9455351381E; Mon, 19 Aug 2013 19:00:56 +0600 (YEKT) Message-ID: From: "Anton Tveretin" To: "Hadriel Kaplan" Date: Mon, 19 Aug 2013 18:54:34 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130819-0, 19.08.2013), Outbound message X-Antivirus-Status: Clean Cc: stir@ietf.org Subject: [stir] H.323 etc. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:01:10 -0000 Obviously, I failed to formulate my question. It was: Is IKES, any other in-band and out-of-band signalling only for SIP or for other clients also? In other words, will there be validators in non-SIP networks? (or rather, do we expect them?). If no, we expect non-SIP networks just to transfer any extra information transparently (as UUI). So do not bother gatekeepers with it. If yes, that information should be delivered to wherever a validator might be. Also, I think PSTN/ISDN is "sterile" and trusted. I do not expect validators to be deployed inside native PSTN soon, but ingress gateway must try their best. I see one more problem here: how to supply keys (certificates) there? Sincerely yours, Anton. From hadriel.kaplan@oracle.com Mon Aug 19 06:51:09 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1527A21F99B7 for ; Mon, 19 Aug 2013 06:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86ClqqZeX4tt for ; Mon, 19 Aug 2013 06:51:02 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id E2AD621F9A74 for ; Mon, 19 Aug 2013 06:51:01 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JDownM031166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Aug 2013 13:50:59 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JDovP4003692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 13:50:57 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JDoucI022536; Mon, 19 Aug 2013 13:50:56 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Aug 2013 06:50:56 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Hadriel Kaplan X-Priority: 3 In-Reply-To: Date: Mon, 19 Aug 2013 09:50:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Anton Tveretin X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] H.323 etc. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:51:09 -0000 Hi Anton, Your question sounds like you're asking for a definitive answer - as if = the group has come to a consensus regarding this topic already. No = consensus decisions been reached beyond the the stuff in the current = charter, as far as I know. The STIR group isn't even a Working Group = yet. :) Comments inline... On Aug 19, 2013, at 8:54 AM, Anton Tveretin wrote: > Obviously, I failed to formulate my question. > It was: Is IKES, any other in-band and out-of-band signalling only for = SIP or for other clients also? In other words, will there be validators = in non-SIP networks? (or rather, do we expect them?). The focus is clearly on SIP, but at least in IKES it allows SS7 and XMPP = devices to be validators. The question of "do we expect them?" is a = hard one, because I don't have a crystal ball. As far as I know XMPP = rarely uses E.164 numbers and rarely is involved in PSTN-style calls; so = I don't expect it to do IKES anytime soon. But if XMPP usage continues = to grow, it's possible that someday it might need to do it. The SS7 = side is also hard to gauge - in the US and Europe the SS7 market is = basically stagnant. One can still buy SS7 equipment from multiple = vendors, but there isn't a lot of R&D spent in it. It's possible though = that a SS7 STP be upgraded to do IKES validation, if IKES is popular = enough. > If no, we expect non-SIP networks just to transfer any extra = information transparently (as UUI). So do not bother gatekeepers with = it. I expect that to also occur, yes. > If yes, that information should be delivered to wherever a validator = might be. The IKES mechanism is an "in-band" one. An in-band mechanism follows = the call signaling path, by definition. If the validator is not in the = call signaling path, I don't believe it's in scope for an in-band = mechanism. > Also, I think PSTN/ISDN is "sterile" and trusted. I do not expect = validators to be deployed inside native PSTN soon, but ingress gateway = must try their best. I doubt ingress gateways to the PSTN will perform validation. > I see one more problem here: how to supply keys (certificates) there? There have been several proposals for how the keys/certs are retrieved = by validators. The CIDER draft is one, and draft-4474bis has another. -hadriel From rlb@ipv.sx Mon Aug 19 07:54:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2119311E827E for ; Mon, 19 Aug 2013 07:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlMGykgCgVxH for ; Mon, 19 Aug 2013 07:53:56 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 93B3821F8417 for ; Mon, 19 Aug 2013 07:53:52 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd6so5564010obb.33 for ; Mon, 19 Aug 2013 07:53:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=+XMrQhud6TdE0KlCCvDgeFVcFWKFB+mhjR6uwqoTeAo=; b=nxRPnTxt6/p2uxSG6Nk+ZPf4TpkmJtAtETfW50eDzLJbaHEeq68NFYjzNHSZl+bC8T h8xWGck4Rpq4b7bDxCsAchWfcO1jYpftEqqfVTo/EtpJpnyziWc7Vco3rzMlWTfAbfdW R5cbckNhn36Rxz0m7MjuNsm4vG63jbcg88c6vAUJjJ1WMTvIdI5iebAGb5BbkLL9wBBh O6dKzimgv7TPCXIJgUXJ8dvpTa3WyC4aONIpBZYkZqu5wjfg+rrQbGXdxzEnnGXPjwRJ 43ctnth+FPpEaHFz0Yd0zyVZsSqBTncDhwZtif3fIN6v9L9WuhdYlUls5Amzc+rhtHTu 80Hg== X-Gm-Message-State: ALoCoQllpv3NUUS59cmdDnWcRWwBfNlq4zLRvzTSecfG89ipc7wfgQDe7jrTidEA5tNxqEQW76zm MIME-Version: 1.0 X-Received: by 10.60.140.168 with SMTP id rh8mr2413057oeb.76.1376924032063; Mon, 19 Aug 2013 07:53:52 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Mon, 19 Aug 2013 07:53:52 -0700 (PDT) X-Originating-IP: [192.1.255.218] Date: Mon, 19 Aug 2013 10:53:52 -0400 Message-ID: From: Richard Barnes To: "stir@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e4c46d06a6704e44e1b4b Subject: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 14:54:01 -0000 --047d7b2e4c46d06a6704e44e1b4b Content-Type: text/plain; charset=ISO-8859-1 Dear STIR, In response to some comments from the IESG, we've made a few changes to the STIR charter. The new proposed text has been uploaded to the datatracker: Diff here: < http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/charter/charter-ietf-stir-00-01.txt&url2=http://www.ietf.org/charter/charter-ietf-stir-00-03.txt > Please reply to this message by Wednesday, 21 Aug if you have any issues with these changes. Thanks, --Richard --047d7b2e4c46d06a6704e44e1b4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear STIR,

In response to some comments= from the IESG, we've made a few changes to the STIR charter. The new p= roposed text has been uploaded to the datatracker:
Diff here:

Please reply to this message by Wednesday, 21 Aug if yo= u have any issues with these changes.

Thanks,
--Richard






--047d7b2e4c46d06a6704e44e1b4b-- From Henning.Schulzrinne@fcc.gov Mon Aug 19 08:18:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D62311E8116 for ; Mon, 19 Aug 2013 08:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=1.795, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FLSiEgyk-lg for ; Mon, 19 Aug 2013 08:18:41 -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 440FF11E8102 for ; Mon, 19 Aug 2013 08:18:40 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Richard Barnes' , "stir@ietf.org" Thread-Topic: [stir] Charter revisions after IESG review Thread-Index: AQHOnOv+xAJXoHLyQkiamwLPdTx5cpmcpGOQ Date: Mon, 19 Aug 2013 15:18:38 +0000 References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FBBA99Ep2pxmb13fccnetw_" MIME-Version: 1.0 Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 15:18:45 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FBBA99Ep2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My suggestion would be to replaced "based on the PSTN" with "based on SS7 o= r similar TDM technologies" or "based on circuit-switched technologies". Th= e new text implies that SIP-based systems are not part of the PSTN. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Monday, August 19, 2013 10:54 AM To: stir@ietf.org Subject: [stir] Charter revisions after IESG review Dear STIR, In response to some comments from the IESG, we've made a few changes to the= STIR charter. The new proposed text has been uploaded to the datatracker: Diff here: Please reply to this message by Wednesday, 21 Aug if you have any issues wi= th these changes. Thanks, --Richard --_000_E6A16181E5FD2F46B962315BB05962D01FBBA99Ep2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My suggestion would be to= replaced “based on the PSTN” with “based on SS7 or simil= ar TDM technologies” or “based on circuit-switched technologies= ”. The new text implies that SIP-based systems are not part of the PSTN.

 <= /p>

From: stir-bou= nces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, August 19, 2013 10:54 AM
To: stir@ietf.org
Subject: [stir] Charter revisions after IESG review

 

Dear STIR,

 

In response to some comments from the IESG, we've ma= de a few changes to the STIR charter. The new proposed text has been upload= ed to the datatracker:

Diff here:

 

Please reply to this message by Wednesday, 21 Aug if= you have any issues with these changes.

 

Thanks,

--Richard

 

 

 

 

 

 

--_000_E6A16181E5FD2F46B962315BB05962D01FBBA99Ep2pxmb13fccnetw_-- From kent@bbn.com Mon Aug 19 08:28:04 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C571411E8285 for ; Mon, 19 Aug 2013 08:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj0-MQ+7lbW0 for ; Mon, 19 Aug 2013 08:27:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 307FA11E8288 for ; Mon, 19 Aug 2013 08:27:58 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49522 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBRN6-000Lfs-RD; Mon, 19 Aug 2013 11:27:57 -0400 Message-ID: <5212397C.7000205@bbn.com> Date: Mon, 19 Aug 2013 11:27:56 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "hadriel.kaplan@oracle.com" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> In-Reply-To: <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 15:28:04 -0000 Hadriel, > ... > > We know we can't just trust callerid4u to claim any CNAM it wanted to. So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). This aspect of your proposal already raises several concerns in my mind: - Jane Doe is not a globally unique name, so a called party can't assume that the caller is the Jane Doe that comes to mind - I strongly doubt that there is a single CA that could (should) be trusted to the identity of every caller in every country. if we have per-country CAs we start getting close to the problems we have in the browser environment. - As a rule, the best CAs are ones that are authoritative for the attributes for which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally meaningful), and if one tries to tie both attributes into one cert ... My bottom line is that I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding. Steve From oej@edvina.net Mon Aug 19 08:29:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B5C11E8285 for ; Mon, 19 Aug 2013 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fvR-G-Km-nr for ; Mon, 19 Aug 2013 08:29:31 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C389611E8288 for ; Mon, 19 Aug 2013 08:29:28 -0700 (PDT) Received: from [192.168.40.29] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 1DBE793DE3C; Mon, 19 Aug 2013 15:29:26 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_239EBADC-7A12-4619-88FF-3D49C525E0A6" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 19 Aug 2013 17:29:25 +0200 Message-Id: <11B4D67A-623D-4A67-BD42-8EE1C513D2BF@edvina.net> References: To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) Cc: 'Richard Barnes' , "stir@ietf.org" , "Olle E. Johansson" Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 15:29:31 -0000 --Apple-Mail=_239EBADC-7A12-4619-88FF-3D49C525E0A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 " =09 The working group welcomes input form potential implementors or = operators=09 of parts of the STIR system.=20 " form =3D> from I'm not very comfortable with "STIR system" either. "Platforms based on = solutions created by this wg" or something along those lines would feel = better. /O 19 aug 2013 kl. 17:18 skrev Henning Schulzrinne = : > My suggestion would be to replaced =93based on the PSTN=94 with =93based= on SS7 or similar TDM technologies=94 or =93based on circuit-switched = technologies=94. The new text implies that SIP-based systems are not = part of the PSTN. > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Richard Barnes > Sent: Monday, August 19, 2013 10:54 AM > To: stir@ietf.org > Subject: [stir] Charter revisions after IESG review > =20 > Dear STIR, > =20 > In response to some comments from the IESG, we've made a few changes = to the STIR charter. The new proposed text has been uploaded to the = datatracker: > > Diff here: > = > =20 > Please reply to this message by Wednesday, 21 Aug if you have any = issues with these changes. > =20 > Thanks, > --Richard > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_239EBADC-7A12-4619-88FF-3D49C525E0A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 "
=
The working group welcomes input form potential implementors or = operators
of = parts of the STIR system. =
"
form =3D> = from

I'm not very comfortable with "STIR = system" either. "Platforms based on solutions created by this wg" or = something along those lines would feel = better.

/O

19 aug 2013 kl. = 17:18 skrev Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>:

My suggestion would be = to replaced =93based on the PSTN=94 with =93based on SS7 or similar TDM = technologies=94 or =93based on circuit-switched technologies=94. The new = text implies that SIP-based systems are not part of the = PSTN.
 
 stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Monday, August 19, 2013 = 10:54 AM
To: stir@ietf.org
Subject: [stir] Charter revisions = after IESG review
Dear = STIR,
In = response to some comments from the IESG, we've made a few changes to the = STIR charter. The new proposed text has been uploaded to the = datatracker:
Diff = here:
 
Please reply to this message by Wednesday, 21 Aug = if you have any issues with these = changes.
Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 15:57:07 -0000 --e89a8ff1c024ab000804e44efcf9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Aug 19, 2013 at 11:18 AM, Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> wrote: > My suggestion would be to replaced =93based on the PSTN=94 with =93based= on > SS7 or similar TDM technologies=94 or =93based on circuit-switched > technologies=94. The new text implies that SIP-based systems are not part= of > the PSTN. > Thanks. Revised to "circuit-switched technologies" in my working copy. --Richard > **** > > ** ** > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, August 19, 2013 10:54 AM > *To:* stir@ietf.org > *Subject:* [stir] Charter revisions after IESG review**** > > ** ** > > Dear STIR,**** > > ** ** > > In response to some comments from the IESG, we've made a few changes to > the STIR charter. The new proposed text has been uploaded to the > datatracker:**** > > **** > > Diff here:**** > > < > http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.ietf.org/chart= er/charter-ietf-stir-00-01.txt&url2=3Dhttp://www.ietf.org/charter/charter-i= etf-stir-00-03.txt > >**** > > ** ** > > Please reply to this message by Wednesday, 21 Aug if you have any issues > with these changes.**** > > ** ** > > Thanks,**** > > --Richard**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > --e89a8ff1c024ab000804e44efcf9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 19, 2013 at 11:18 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

My suggestion would be to replaced =93based on the PS= TN=94 with =93based on SS7 or similar TDM technologies=94 or =93based on ci= rcuit-switched technologies=94. The new text implies that SIP-based systems are not part of the PSTN.


Thanks. =A0Revised to "circ= uit-switched technologies" in my working copy.
--Richard=
=A0

=A0

From: stir-bounc= es@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, August 19, 2013 10:54 AM
To: stir@ietf.org=
Subject: [stir] Charter revisions after IESG review

=A0

Dear STIR,

=A0

In response to some comments from the IESG, we've made a = few changes to the STIR charter. The new proposed text has been uploaded to= the datatracker:

Diff here:

=A0

Please reply to this message by Wednesday, 21 Aug if you have= any issues with these changes.

=A0

Thanks,

--Richard

=A0

=A0

=A0

=A0

=A0

<= u>=A0


--e89a8ff1c024ab000804e44efcf9-- From rlb@ipv.sx Mon Aug 19 08:57:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CE711E8114 for ; Mon, 19 Aug 2013 08:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiWAZyJbdtaO for ; Mon, 19 Aug 2013 08:57:35 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id D342511E8106 for ; Mon, 19 Aug 2013 08:57:33 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so6240929oag.4 for ; Mon, 19 Aug 2013 08:57:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hjctrc309MvvuPzTrOXGVgSARoMTmkSKeR7mmcAiKc8=; b=iCfvOf1g5v22leFAH5YA9C1M5DP+VjxUDDG5VjxhYdN30z3eOsTYZFUgNAGVtkaP3W W717dR5XBj2/qdzLWCmlq9IGEJOVcdVIbO/ciWnibX58BZ8SUz8IUtFE5egyLFEh4fkz GOZU31IxIH7fXQUMTMbMN9hIiMKiZE5vsSGDc0D5/IsCBA6vsU/KgZfIrf7rtmjKPl9z iUzTJm/QFi5nh8DzOUT0Ivd4Gqc/VFoHuuado76LZZus/Gy5jrNrsYcr6rD/HAcZAQjb w6FxbE/lH/71KmmS7PeH5GaQAoMRk1//YBriNsItcKtMgI66qb8zfdMC09SKWo8oiq3p 78kA== X-Gm-Message-State: ALoCoQlBLWitC68E676qEDZneYDFQH8sutMhTrnqq9jW+2UyNnVWv+L/NtgKRWLgRzZRWmNiU26+ MIME-Version: 1.0 X-Received: by 10.182.199.74 with SMTP id ji10mr2677478obc.69.1376927853191; Mon, 19 Aug 2013 08:57:33 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Mon, 19 Aug 2013 08:57:33 -0700 (PDT) X-Originating-IP: [192.1.255.218] In-Reply-To: <11B4D67A-623D-4A67-BD42-8EE1C513D2BF@edvina.net> References: <11B4D67A-623D-4A67-BD42-8EE1C513D2BF@edvina.net> Date: Mon, 19 Aug 2013 11:57:33 -0400 Message-ID: From: Richard Barnes To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=e89a8ff1c02492273704e44effae Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 15:57:50 -0000 --e89a8ff1c02492273704e44effae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Aug 19, 2013 at 11:29 AM, Olle E. Johansson wrote: > " > The working group welcomes input form potential implementors or operator= s of > parts of the STIR system. > " > form =3D> from > > I'm not very comfortable with "STIR system" either. "Platforms based on > solutions created by this wg" or something along those lines would feel > better. > Revised to "... implementors or operators of technologies developed by this working group" in my working copy. --Richard > > /O > > 19 aug 2013 kl. 17:18 skrev Henning Schulzrinne < > Henning.Schulzrinne@fcc.gov>: > > My suggestion would be to replaced =93based on the PSTN=94 with =93based = on SS7 > or similar TDM technologies=94 or =93based on circuit-switched technologi= es=94. > The new text implies that SIP-based systems are not part of the PSTN.**** > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf O= f > *Richard Barnes > *Sent:* Monday, August 19, 2013 10:54 AM > *To:* stir@ietf.org > *Subject:* [stir] Charter revisions after IESG review**** > ** ** > Dear STIR,**** > ** ** > In response to some comments from the IESG, we've made a few changes to > the STIR charter. The new proposed text has been uploaded to the > datatracker:**** > **** > Diff here:**** > < > http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.ietf.org/chart= er/charter-ietf-stir-00-01.txt&url2=3Dhttp://www.ietf.org/charter/charter-i= etf-stir-00-03.txt > >**** > ** ** > Please reply to this message by Wednesday, 21 Aug if you have any issues > with these changes.**** > ** ** > Thanks,**** > --Richard**** > ** ** > ** ** > ** ** > ** ** > ** ** > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > > --e89a8ff1c02492273704e44effae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 19, 2013 at 11:29 AM, Olle E. Johansson <oej@edv= ina.net> wrote:
"
<= /td> The working group welcomes input form pote= ntial implementors or operators = of parts of the STIR system. <= /tr>
"
form =3D> from

I'm not very comfortable with "STIR system" either. &qu= ot;Platforms based on solutions created by this wg" or something along= those lines would feel better.

Revised to "... imp= lementors or operators of technologies developed by this working group"= ; in my working copy.

--Richard

=A0

/O

19 aug 2013 kl. 17:18 skrev= Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>:

My suggestion wo= uld be to replaced =93based on the PSTN=94 with =93based on SS7 or similar = TDM technologies=94 or =93based on circuit-switched technologies=94. The ne= w text implies that SIP-based systems are not part of the PSTN.
=A0
From:=A0= stir-bounces@ietf.org=A0<= /span>[mailto:stir-bounces@ietf.org]=A0On Behalf Of=A0Richard Barnes
Sent:=A0Monday, August 19, 2013 10:54 AM
To:<= span>=A0stir@ietf.org
Subject:=A0[stir] Charter revisions after IESG review
=A0
D= ear STIR,
=A0
In response to some comments from the IESG, we've made a few changes to= the STIR charter. The new proposed text has been uploaded to the datatrack= er:
Diff here:
=A0
Please reply to this message by Wednesday, 21 Aug if you have any issues wi= th these changes.
<= /u>=A0
Thanks,
--Richard
=A0
=A0
=A0<= /div>
=A0
=A0<= /div>
=A0
____________________________________________= ___
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman= /listinfo/stir


--e89a8ff1c02492273704e44effae-- From Henning.Schulzrinne@fcc.gov Mon Aug 19 09:02:29 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D9611E8114 for ; Mon, 19 Aug 2013 09:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqq5iiWrcX3P for ; Mon, 19 Aug 2013 09:02:25 -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 8D91B11E810E for ; Mon, 19 Aug 2013 09:02:25 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Stephen Kent' , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: Ac6c9Ozge0DbBLvpSRWm6Pzx5g4CWg== Date: Mon, 19 Aug 2013 16:02:24 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:02:30 -0000 In general, given that many users base their decision on how to treat a cal= l on the textual caller ID, rather than the number, I think this is indeed = a problem we should think about, even if the result is to punt this to anot= her effort. As per Steve's comment, there is value of tying the provider of= the name to the textual identifier, as it reduces the threat of DigiNotar-= style attacks.=20 I have a number of hypotheses: (1) Validating the names of commercial entities is more important than that= of individuals. (Individuals also sometimes have legitimate reasons to pro= vide partial information. For example, it's been a long tradition, whether = justified by evidence or not, for households of single women to use initial= s rather than full first names in directory listings and thus also CLID.) T= he numbers shown to the public are likely public knowledge, so concerns abo= ut keeping them secret may be lower. (2) Legitimate businesses have an incentive to provide correct information = that can be validated. The incentives of other parties are, shall we say, m= ixed. (3) Financial and other entities at significant risk of fraud are probably = reasonably-well resourced and represented in databases such as the Dun&Brad= street registry or government databases. (4) Whitelisting is easier than blacklisting. (5) It is helpful if name abusers can be located quickly, as that facilitat= es legal remedies. Thus, to get to the solution space, I can see three directions that might b= e productive: (1) Provide an indication by a trusted party (such as the terminating provi= der) as to the provenance of the textual callerID information. This will th= en allow other tools to provide, for example, some visual indication of the= trustworthiness, without the provider having to make that editorial judgme= nt.=20 (2) Provide a whois-like mechanism for more extensive information at least = equivalent to EV certs, possibly signed by the same key used for numbers, t= o prevent the CA issues. This would only be available to smartphones (but a= lso case (1)) and is primarily meant to identify commercial identities. I s= ee this as a separate effort; expect to hear more about this shortly. It ne= eds to be cryptographically-coupled with the E.164 mechanism, even if provi= ded by another party such as D&B. (3) For the SIP display-name case with end-to-end delivery, it would be hel= pful to have a way to sign both name and number. This doesn't deal with imp= ostors or look-alike names, but other attacks outlined earlier. As number assignment goes beyond the realm of "few big companies with regul= ator visitors to the regulators" (in the FCC context, the "blue badge peopl= e"), we will face the same or similar whois-type issues that ICANN is deali= ng with. Fortunately, we have somewhat more local enforcement mechanisms, s= o the problem may be more tractable. As with number spoofing, I think an achievable goal is that unsigned, untra= ceable textual caller ID will be seen as dodgy and increase the chances tha= t callees will not answer the call (or let it go to voicemail), increasing = the incentive for legitimate call originators to provide identifying inform= ation. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ste= phen Kent Sent: Monday, August 19, 2013 11:28 AM To: hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Hadriel, > ... > > We know we can't just trust callerid4u to claim any CNAM it wanted to. S= o let's say instead of trusting callerid4u, we designated some common CA to= verify and sign CNAM information for everyone, and everyone has to trust t= hem. This CA used various sources of information and verification to creat= e a "certificate" that said "for this phone number X, the user's name is Ja= ne Doe", or maybe "for the holder of the private key for this public key, t= he user's name is Jane Doe" (which is basically what web certificates say). This aspect of your proposal already raises several concerns in my mind: - Jane Doe is not a globally unique name, so a called party can't assume th= at the caller is the Jane Doe that comes to mind - I strongly doubt that there is a single CA that could (should) be trusted= to the identity of every caller in every country. if we have per-country C= As we start getting close to the problems we have in the browser environmen= t. - As a rule, the best CAs are ones that are authoritative for the attribute= s for which they vouch. For phone numbers a lot of folks seem confident tha= t we have the right players to perform this function. For common names, we = do not (until you add a lot of context, which is often not universally mean= ingful), and if one tries to tie both attributes into one cert ... My bottom line is that I don't believe in the web CA model; it has failed. = DANE is a much better approach, becuase it aligns name space management and= public key binding. Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Aug 19 09:02:33 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB1E11E829F for ; Mon, 19 Aug 2013 09:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb59J-E7iQSH for ; Mon, 19 Aug 2013 09:02:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7708011E8113 for ; Mon, 19 Aug 2013 09:02:27 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JG2MBS032570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Aug 2013 16:02:22 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JG2Lui007667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 16:02:21 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JG2KeD022323; Mon, 19 Aug 2013 16:02:21 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Aug 2013 09:02:20 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5212397C.7000205@bbn.com> Date: Mon, 19 Aug 2013 12:02:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <5! 212397C.7000205@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:02:33 -0000 Of course, but that's why I later said "if you believe in a CA model for = that". If you don't believe in a CA model for such data, there's = nothing we can do to improve upon it, since there is no authority model = we could really create for human names. -hadriel On Aug 19, 2013, at 11:27 AM, Stephen Kent wrote: > Hadriel, >=20 >=20 >> ... >>=20 >> We know we can't just trust callerid4u to claim any CNAM it wanted = to. So let's say instead of trusting callerid4u, we designated some = common CA to verify and sign CNAM information for everyone, and everyone = has to trust them. This CA used various sources of information and = verification to create a "certificate" that said "for this phone number = X, the user's name is Jane Doe", or maybe "for the holder of the private = key for this public key, the user's name is Jane Doe" (which is = basically what web certificates say). > This aspect of your proposal already raises several concerns in my = mind: >=20 > - Jane Doe is not a globally unique name, so a called party can't = assume that > the caller is the Jane Doe that comes to mind >=20 > - I strongly doubt that there is a single CA that could (should) be = trusted to > the identity of every caller in every country. if we have per-country > CAs we start getting close to the problems we have in the browser = environment. >=20 > - As a rule, the best CAs are ones that are authoritative for the = attributes for > which they vouch. For phone numbers a lot of folks seem confident that = we > have the right players to perform this function. For common names, we = do > not (until you add a lot of context, which is often not universally > meaningful), and if one tries to tie both attributes into one cert ... >=20 > My bottom line is that I don't believe in the web CA model; it has = failed. DANE is > a much better approach, becuase it aligns name space management and = public key binding. >=20 >=20 > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Aug 19 09:05:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA19D21F99C3 for ; Mon, 19 Aug 2013 09:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae3pIVNEpbcd for ; Mon, 19 Aug 2013 09:05:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6A36811E810E for ; Mon, 19 Aug 2013 09:05:44 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JG5fp4003686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Aug 2013 16:05:42 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JG5e3I003824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 16:05:40 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JG5dPK016425; Mon, 19 Aug 2013 16:05:39 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Aug 2013 09:05:39 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 19 Aug 2013 12:05:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <555AC740-B6D3-49F1-BE7B-73AABCB1655F@oracle.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:05:49 -0000 I don't know what this means: It is important to note that while the main focus of this = working group=09 is telephone numbers, the STIR working group will not develop = any=09 technologies based on the PSTN. What was the rationale behind adding that, and what was the intent? -hadriel On Aug 19, 2013, at 10:53 AM, Richard Barnes wrote: > Dear STIR, >=20 > In response to some comments from the IESG, we've made a few changes = to the STIR charter. The new proposed text has been uploaded to the = datatracker: > > Diff here: > = >=20 > Please reply to this message by Wednesday, 21 Aug if you have any = issues with these changes. >=20 > Thanks, > --Richard >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Mon Aug 19 09:11:52 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA6921F9B19 for ; Mon, 19 Aug 2013 09:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.047 X-Spam-Level: X-Spam-Status: No, score=-100.047 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VM6ODbQjkaB5 for ; Mon, 19 Aug 2013 09:11:47 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 70D6921F880F for ; Mon, 19 Aug 2013 09:11:43 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb10so4803306pad.9 for ; Mon, 19 Aug 2013 09:11:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=29XcPI4sKiiotgRWftlkSEBs3pkLljF14yxIMtWRu0c=; b=DeGjC78E4rArN8bAqz8IQbyUcl0rd2hRpWzB3IGH10tgJszbgx+cYjaacABeJNRWix 9ZNQ4jvpafzeJnojZOAeOE8C2xRNMantGsRx58XOXOg7fF20ek+uEZPlTgVnEWqas7ki xxLkXR8FMJ3kcUJ2iVjGz9uVFXkOasTavFkEPzfczsc9B/GhaYXtzPutR2vB2Z2X+dP7 BhehEI9hAApEpLjZxdB4EWFpDZvOeLLYhZ+1VZDyKYRVSbIKnpa2O/7Z/jjtk+R6FLjs 0p1eGdUl4lCjF8RMFXLKKJ9DJKqNMq5be5rw3420EBTcLTCd8XKTOicse/NBDh2LFLdS 209A== X-Gm-Message-State: ALoCoQmQFNFvE2HZnKEH+iw84QJX4WNf3DYK7nKjrsr3rCjIXH5d7RHDtw9jjYHPqh893HNVrrIm MIME-Version: 1.0 X-Received: by 10.68.253.227 with SMTP id ad3mr2551403pbd.189.1376928703001; Mon, 19 Aug 2013 09:11:43 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Mon, 19 Aug 2013 09:11:42 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <5212397C.7000205@bbn.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <5212397C.7000205@bbn.com> Date: Mon, 19 Aug 2013 12:11:42 -0400 Message-ID: From: Brian Rosen To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b1630d13946cb04e44f32b7 Cc: "stir@ietf.org" , "hadriel.kaplan@oracle.com" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:11:52 -0000 --047d7b1630d13946cb04e44f32b7 Content-Type: text/plain; charset=ISO-8859-1 I'd like to examine your assertion "I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding." with respect to stir. It seems inevitable that within a country, one entity will have the data. If that isn't the case, then we're going to have long chains of delegations that each would need to be validated. If there is one per country, then there is only one signature per number. That is independent of how credentials are stored. Even if there were a small number of entities per country, that wouldn't change much. The point is that mistakes will be made and the DANE model, applied here, when most records are under control of one or a small number of entities, will be subject to the same issues that allowed the web CA model to fail. What is attractive in DANE is that the DNS delegation is diffuse, so compromise of one entity limits problems. We won't have that situation. I do think that the consequences of a mistake will be much more modest. Brian On Mon, Aug 19, 2013 at 11:27 AM, Stephen Kent wrote: > Hadriel, > > > ... >> >> >> We know we can't just trust callerid4u to claim any CNAM it wanted to. >> So let's say instead of trusting callerid4u, we designated some common CA >> to verify and sign CNAM information for everyone, and everyone has to trust >> them. This CA used various sources of information and verification to >> create a "certificate" that said "for this phone number X, the user's name >> is Jane Doe", or maybe "for the holder of the private key for this public >> key, the user's name is Jane Doe" (which is basically what web certificates >> say). >> > This aspect of your proposal already raises several concerns in my mind: > > - Jane Doe is not a globally unique name, so a called party can't assume > that > the caller is the Jane Doe that comes to mind > > - I strongly doubt that there is a single CA that could (should) be > trusted to > the identity of every caller in every country. if we have per-country > CAs we start getting close to the problems we have in the browser > environment. > > - As a rule, the best CAs are ones that are authoritative for the > attributes for > which they vouch. For phone numbers a lot of folks seem confident that we > have the right players to perform this function. For common names, we do > not (until you add a lot of context, which is often not universally > meaningful), and if one tries to tie both attributes into one cert ... > > My bottom line is that I don't believe in the web CA model; it has failed. > DANE is > a much better approach, becuase it aligns name space management and public > key binding. > > > Steve > > ______________________________**_________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/**listinfo/stir > --047d7b1630d13946cb04e44f32b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'd like to examine your assertion "I don't believe in the= web CA model; it has failed. DANE is
a much better a= pproach, becuase it aligns name space management and public key binding.&qu= ot; with respect to stir.

It seems inevitable that within a country, one entity will have the data= . =A0If that isn't the case, then we're going to have long chains o= f delegations that each would need to be validated. =A0If there is one per = country, then there is only one signature per number. =A0That is independen= t of how credentials are stored.

Even if there were a small num= ber of entities per country, that wouldn't change much.

The point is that mistakes will be made and the DANE model, ap= plied here, when most records are under control of one or =A0a small number= of entities, will be subject to the same issues that allowed the web CA mo= del to fail. =A0What is attractive in DANE is that the DNS delegation is di= ffuse, so compromise of one entity limits problems. =A0We won't have th= at situation.

I do think that the consequences of a mistake will be muc= h more modest.

Brian

<= br>


On Mon, Aug 19, 2013 at 11:27 AM, Stephen Kent <kent@bbn.com> wro= te:
Hadriel,


...


We know we can't just trust callerid4u to claim any CNAM it wanted to. = =A0So let's say instead of trusting callerid4u, we designated some comm= on CA to verify and sign CNAM information for everyone, and everyone has to= trust them. =A0This CA used various sources of information and verificatio= n to create a "certificate" that said "for this phone number= X, the user's name is Jane Doe", or maybe "for the holder of= the private key for this public key, the user's name is Jane Doe"= (which is basically what web certificates say).
This aspect of your proposal already raises several concerns in my mind:
- Jane Doe is not a globally unique name, so a called party can't assum= e that
the caller is the Jane Doe that comes to mind

- I strongly doubt that there is a single CA that could (should) be trusted= to
the identity of every caller in every country. if we have per-country
CAs we start getting close to the problems we have in the browser environme= nt.

- As a rule, the best CAs are ones that are authoritative for the attribute= s for
which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally
meaningful), and if one tries to tie both attributes into one cert ...

My bottom line is that I don't believe in the web CA model; it has fail= ed. DANE is
a much better approach, becuase it aligns name space management and public = key binding.


Steve

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--047d7b1630d13946cb04e44f32b7-- From michael.hammer@yaanatech.com Mon Aug 19 09:14:32 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8C311E82AB for ; Mon, 19 Aug 2013 09:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdyWp3Nn4pQf for ; Mon, 19 Aug 2013 09:14:28 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id D753F11E82AD for ; Mon, 19 Aug 2013 09:14:27 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 19 Aug 2013 09:14:21 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "kent@bbn.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: Ac6c9Ozge0DbBLvpSRWm6Pzx5g4CWgAAX0Kg Date: Mon, 19 Aug 2013 16:14:20 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.107] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0063_01CE9CD5.A1453EC0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:14:32 -0000 ------=_NextPart_000_0063_01CE9CD5.A1453EC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit There is no reason that the digital signature binding a Name to a Number could not be orthogonal and managed independently from the valid sender/Number binding. You could bundle these together, but there may be reasons to keep them separate. With names, you are now talking about a registry with personal information and you may have many folks that do not want their names made public. I could see this as being more valuable for businesses, and that may be one or two orders of magnitude fewer entities to manage. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 19, 2013 12:02 PM To: 'Stephen Kent'; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) In general, given that many users base their decision on how to treat a call on the textual caller ID, rather than the number, I think this is indeed a problem we should think about, even if the result is to punt this to another effort. As per Steve's comment, there is value of tying the provider of the name to the textual identifier, as it reduces the threat of DigiNotar-style attacks. I have a number of hypotheses: (1) Validating the names of commercial entities is more important than that of individuals. (Individuals also sometimes have legitimate reasons to provide partial information. For example, it's been a long tradition, whether justified by evidence or not, for households of single women to use initials rather than full first names in directory listings and thus also CLID.) The numbers shown to the public are likely public knowledge, so concerns about keeping them secret may be lower. (2) Legitimate businesses have an incentive to provide correct information that can be validated. The incentives of other parties are, shall we say, mixed. (3) Financial and other entities at significant risk of fraud are probably reasonably-well resourced and represented in databases such as the Dun&Bradstreet registry or government databases. (4) Whitelisting is easier than blacklisting. (5) It is helpful if name abusers can be located quickly, as that facilitates legal remedies. Thus, to get to the solution space, I can see three directions that might be productive: (1) Provide an indication by a trusted party (such as the terminating provider) as to the provenance of the textual callerID information. This will then allow other tools to provide, for example, some visual indication of the trustworthiness, without the provider having to make that editorial judgment. (2) Provide a whois-like mechanism for more extensive information at least equivalent to EV certs, possibly signed by the same key used for numbers, to prevent the CA issues. This would only be available to smartphones (but also case (1)) and is primarily meant to identify commercial identities. I see this as a separate effort; expect to hear more about this shortly. It needs to be cryptographically-coupled with the E.164 mechanism, even if provided by another party such as D&B. (3) For the SIP display-name case with end-to-end delivery, it would be helpful to have a way to sign both name and number. This doesn't deal with impostors or look-alike names, but other attacks outlined earlier. As number assignment goes beyond the realm of "few big companies with regulator visitors to the regulators" (in the FCC context, the "blue badge people"), we will face the same or similar whois-type issues that ICANN is dealing with. Fortunately, we have somewhat more local enforcement mechanisms, so the problem may be more tractable. As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chances that callees will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Monday, August 19, 2013 11:28 AM To: hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Hadriel, > ... > > We know we can't just trust callerid4u to claim any CNAM it wanted to. So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). This aspect of your proposal already raises several concerns in my mind: - Jane Doe is not a globally unique name, so a called party can't assume that the caller is the Jane Doe that comes to mind - I strongly doubt that there is a single CA that could (should) be trusted to the identity of every caller in every country. if we have per-country CAs we start getting close to the problems we have in the browser environment. - As a rule, the best CAs are ones that are authoritative for the attributes for which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally meaningful), and if one tries to tie both attributes into one cert ... My bottom line is that I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding. Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0063_01CE9CD5.A1453EC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx OTE2MTQxOFowIwYJKoZIhvcNAQkEMRYEFP1B6Zfdd0Fbu7uudrmj3Oj/ZCIwMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAFrRHsiM7GxCFzio9Y84Gvl1/2oQ7+PgwCmt/sBOv fX5ZR37K6xXe+xgB6/RfYevdVsybJIEEDPw3k9SeB1l7bQI7mOAZX2s/ApCJsnCfv1DHJIaO5VcZ 0YcUBu2K0QXOt16I/EAenqAIO3sgA7N404ugoFjrUsAFGsYbYU1tg9qbfvPZIjd8RG6G9uv+lFVG tZVPyNxzDKtfsBpQ1vsFdVU96nNDo6Mzb3JIBUiNy6RyFIyekIrzYzzR43PMmbXYzN1cLQ1mUFA8 zIIR62NPouM4BRxqKx7DRQceDpmdPwPpdNBgfhc2Wm/cLyUJl9N6zlBTvbCOyIgovgXeOqFzGAAA AAAAAA== ------=_NextPart_000_0063_01CE9CD5.A1453EC0-- From Henning.Schulzrinne@fcc.gov Mon Aug 19 09:17:42 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555A511E8298 for ; Mon, 19 Aug 2013 09:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uDvF+FQqlJJ for ; Mon, 19 Aug 2013 09:17:37 -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 1BF7811E8132 for ; Mon, 19 Aug 2013 09:17:36 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' , Stephen Kent Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbCAAZhJ4IAAtYSAgAWUWwCAAAmaAP//vuoA Date: Mon, 19 Aug 2013 16:17:36 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <5! 212397C.7000205@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:17:42 -0000 Human names are hard (and often misleading anyway - even with no ill intent= , "Jim Smith" is likely to be inaccurate for many calls placed from the Smi= th household). Names of incorporated entities are much easier - they are re= gistered in almost all cases, even if not trade-marked, and there are clear= rules for dealing with collisions and right-to-use. As long as non-busines= s entities are prevented from using a corporate name, the potential for mis= leading abuse is greatly reduced. That way, a legitimate entity can register "Cardholder Services" and preven= t its use by others. Rachel is unlikely to file a suit to complain. The idea would be to create a database of names that are "protected", i.e.,= cannot be used without signature. (This would also help for numbers, by th= e way.) Henning=20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Monday, August 19, 2013 12:02 PM To: Stephen Kent Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Of course, but that's why I later said "if you believe in a CA model for th= at". If you don't believe in a CA model for such data, there's nothing we = can do to improve upon it, since there is no authority model we could reall= y create for human names. -hadriel From Henning.Schulzrinne@fcc.gov Mon Aug 19 09:21:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FBD11E829A for ; Mon, 19 Aug 2013 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1TKVJd5igDf for ; Mon, 19 Aug 2013 09:21:41 -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 806D111E812A for ; Mon, 19 Aug 2013 09:21:28 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Michael Hammer' , "kent@bbn.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: Ac6c9Ozge0DbBLvpSRWm6Pzx5g4CWgAAX0KgAABYV1A= Date: Mon, 19 Aug 2013 16:21:26 +0000 References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:21:45 -0000 That's why I mentioned third parties, such as (without any implied endorsem= ent, obviously) D&B. The goal is to allow one or more such third parties, b= ut allow the business to tie their E.164 keypair to that registration. That= seems relatively simple - if the whois-style information contains a signat= ure block with the same private key that's used for the number, the recipie= nt can easily check that they are connected, without the name database bein= g tied in any organizational way to the E.164 database. -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Monday, August 19, 2013 12:14 PM To: Henning Schulzrinne; kent@bbn.com; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework) There is no reason that the digital signature binding a Name to a Number could not be orthogonal and managed independently from the valid sender/Number binding. You could bundle these together, but there may be reasons to keep them separate. With names, you are now talking about a registry with personal information and you may have many folks that do not want their names made public. I could see this as being more valuable for businesses, and that may be one or two orders of magnitude fewer entities to manage. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 19, 2013 12:02 PM To: 'Stephen Kent'; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) In general, given that many users base their decision on how to treat a cal= l on the textual caller ID, rather than the number, I think this is indeed a problem we should think about, even if the result is to punt this to anothe= r effort. As per Steve's comment, there is value of tying the provider of the name to the textual identifier, as it reduces the threat of DigiNotar-style attacks.=20 I have a number of hypotheses: (1) Validating the names of commercial entities is more important than that of individuals. (Individuals also sometimes have legitimate reasons to provide partial information. For example, it's been a long tradition, whether justified by evidence or not, for households of single women to use initials rather than full first names in directory listings and thus also CLID.) The numbers shown to the public are likely public knowledge, so concerns about keeping them secret may be lower. (2) Legitimate businesses have an incentive to provide correct information that can be validated. The incentives of other parties are, shall we say, mixed. (3) Financial and other entities at significant risk of fraud are probably reasonably-well resourced and represented in databases such as the Dun&Bradstreet registry or government databases. (4) Whitelisting is easier than blacklisting. (5) It is helpful if name abusers can be located quickly, as that facilitates legal remedies. Thus, to get to the solution space, I can see three directions that might b= e productive: (1) Provide an indication by a trusted party (such as the terminating provider) as to the provenance of the textual callerID information. This will then allow other tools to provide, for example, some visual indication of the trustworthiness, without the provider having to make that editorial judgment.=20 (2) Provide a whois-like mechanism for more extensive information at least equivalent to EV certs, possibly signed by the same key used for numbers, t= o prevent the CA issues. This would only be available to smartphones (but als= o case (1)) and is primarily meant to identify commercial identities. I see this as a separate effort; expect to hear more about this shortly. It needs to be cryptographically-coupled with the E.164 mechanism, even if provided by another party such as D&B. (3) For the SIP display-name case with end-to-end delivery, it would be helpful to have a way to sign both name and number. This doesn't deal with impostors or look-alike names, but other attacks outlined earlier. As number assignment goes beyond the realm of "few big companies with regulator visitors to the regulators" (in the FCC context, the "blue badge people"), we will face the same or similar whois-type issues that ICANN is dealing with. Fortunately, we have somewhat more local enforcement mechanisms, so the problem may be more tractable. As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chance= s that callees will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Monday, August 19, 2013 11:28 AM To: hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Hadriel, > ... > > We know we can't just trust callerid4u to claim any CNAM it wanted to. S= o let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). This aspect of your proposal already raises several concerns in my mind: - Jane Doe is not a globally unique name, so a called party can't assume that the caller is the Jane Doe that comes to mind - I strongly doubt that there is a single CA that could (should) be trusted to the identity of every caller in every country. if we have per-country CA= s we start getting close to the problems we have in the browser environment. - As a rule, the best CAs are ones that are authoritative for the attribute= s for which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally meaningful), and if one tries to tie both attributes into one cert ... My bottom line is that I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding. Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Mon Aug 19 09:21:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEA711E8113 for ; Mon, 19 Aug 2013 09:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57OREM63UcPk for ; Mon, 19 Aug 2013 09:21:43 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 99B0511E812B for ; Mon, 19 Aug 2013 09:21:43 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 19 Aug 2013 09:21:43 -0700 From: Michael Hammer To: "br@brianrosen.net" , "kent@bbn.com" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAWUWwCAAAw7AP//i/gw Date: Mon, 19 Aug 2013 16:21:43 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2A4B0@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <5212397C.7000205@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.107] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0068_01CE9CD6.A98A7180" MIME-Version: 1.0 Cc: "stir@ietf.org" , "hadriel.kaplan@oracle.com" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:21:48 -0000 ------=_NextPart_000_0068_01CE9CD6.A98A7180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0069_01CE9CD6.A98A7180" ------=_NextPart_001_0069_01CE9CD6.A98A7180 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Depends on which end of the telescope you are looking through. I could argue that having the authority aspect diffused leads to the very problem that we are trying to solve. So, you end up with a system that very precisely asserts the wrong information. The longer the chain of delegation the higher probability of error. Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, August 19, 2013 12:12 PM To: Stephen Kent Cc: stir@ietf.org; hadriel.kaplan@oracle.com Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I'd like to examine your assertion "I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding." with respect to stir. It seems inevitable that within a country, one entity will have the data. If that isn't the case, then we're going to have long chains of delegations that each would need to be validated. If there is one per country, then there is only one signature per number. That is independent of how credentials are stored. Even if there were a small number of entities per country, that wouldn't change much. The point is that mistakes will be made and the DANE model, applied here, when most records are under control of one or a small number of entities, will be subject to the same issues that allowed the web CA model to fail. What is attractive in DANE is that the DNS delegation is diffuse, so compromise of one entity limits problems. We won't have that situation. I do think that the consequences of a mistake will be much more modest. Brian On Mon, Aug 19, 2013 at 11:27 AM, Stephen Kent wrote: Hadriel, ... We know we can't just trust callerid4u to claim any CNAM it wanted to. So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). This aspect of your proposal already raises several concerns in my mind: - Jane Doe is not a globally unique name, so a called party can't assume that the caller is the Jane Doe that comes to mind - I strongly doubt that there is a single CA that could (should) be trusted to the identity of every caller in every country. if we have per-country CAs we start getting close to the problems we have in the browser environment. - As a rule, the best CAs are ones that are authoritative for the attributes for which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally meaningful), and if one tries to tie both attributes into one cert ... My bottom line is that I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding. Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_001_0069_01CE9CD6.A98A7180 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Depends on which end of the telescope you are looking = through.

I could argue that having the authority aspect diffused leads to the = very problem that we are trying to solve.

So, you end up with a system that very precisely asserts the wrong = information.

The longer the chain of delegation the higher probability of = error.

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Brian Rosen
Sent: Monday, August 19, 2013 12:12 = PM
To: Stephen Kent
Cc: stir@ietf.org; = hadriel.kaplan@oracle.com
Subject: Re: [stir] Early Homework = (was Re: Moving from BOF to Charter)

 

I'd = like to examine your assertion "I don't = believe in the web CA model; it has failed. DANE is
a much better = approach, becuase it aligns name space management and public key = binding." with respect to stir.

 

It seems = inevitable that within a country, one entity will have the data. =  If that isn't the case, then we're going to have long chains of = delegations that each would need to be validated.  If there is one = per country, then there is only one signature per number.  That is = independent of how credentials are = stored.

 

Even = if there were a small number of entities per country, that wouldn't = change much.

 

The = point is that mistakes will be made and the DANE model, applied here, = when most records are under control of one or  a small number of = entities, will be subject to the same issues that allowed the web CA = model to fail.  What is attractive in DANE is that the DNS = delegation is diffuse, so compromise of one entity limits problems. =  We won't have that situation.

 

I do = think that the consequences of a mistake will be much more = modest.

 

Brian

 

 

 

On Mon, Aug 19, 2013 at 11:27 AM, Stephen Kent <kent@bbn.com> = wrote:

Hadriel,

...



We = know we can't just trust callerid4u to claim any CNAM it wanted to. =  So let's say instead of trusting callerid4u, we designated some = common CA to verify and sign CNAM information for everyone, and everyone = has to trust them.  This CA used various sources of information and = verification to create a "certificate" that said "for = this phone number X, the user's name is Jane Doe", or maybe = "for the holder of the private key for this public key, the user's = name is Jane Doe" (which is basically what web certificates = say).

This aspect of your = proposal already raises several concerns in my mind:

- Jane Doe = is not a globally unique name, so a called party can't assume = that
the caller is the Jane Doe that comes to mind

- I = strongly doubt that there is a single CA that could (should) be trusted = to
the identity of every caller in every country. if we have = per-country
CAs we start getting close to the problems we have in the = browser environment.

- As a rule, the best CAs are ones that are = authoritative for the attributes for
which they vouch. For phone = numbers a lot of folks seem confident that we
have the right players = to perform this function. For common names, we do
not (until you add = a lot of context, which is often not universally
meaningful), and if = one tries to tie both attributes into one cert ...

My bottom line = is that I don't believe in the web CA model; it has failed. DANE is
a = much better approach, becuase it aligns name space management and public = key binding.


Steve


_______________________________________________
= stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 

------=_NextPart_001_0069_01CE9CD6.A98A7180-- ------=_NextPart_000_0068_01CE9CD6.A98A7180 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx OTE2MjE0MlowIwYJKoZIhvcNAQkEMRYEFAPmhalbFzyVRNm7+EDa+1MSZd6VMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAX2tPwsoCybX/LbeU9UpZsARe/1Mg/zOByU++P2f+ wekK34oF8xkk+MjW9JPWdv+2uuTEQXK7vIZJdRNZF7bYwdZ82BS2EUDCE19kWjCyOOoRAohDe53i AHtpWXanko7h7mzzvN7h3v97i3Uo6fp1kWcnSS0/kIh+Vlwgx/FYM+cymESTKfetAlCA+0R4imKB lZxNBHhohH/eqeA+gclhQBBdu0gFXT5ozaQH4yvWUekXzLS79B0YNWzaTqXXI2lYIce6qynPCpjt jIB2lythnQ9uIVLZLanbFK6PLtGrnOhfgc2/o0PCDPMsVxi7sxlKHjbzkMDb9xQYrhhNWSjuvwAA AAAAAA== ------=_NextPart_000_0068_01CE9CD6.A98A7180-- From pp3129@att.com Mon Aug 19 09:28:22 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F22311E82BF for ; Mon, 19 Aug 2013 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGi-RVx7oMcF for ; Mon, 19 Aug 2013 09:28:16 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id C8EA511E82BB for ; Mon, 19 Aug 2013 09:27:55 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b8742125.78e74940.6607997.00-589.18314706.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 19 Aug 2013 16:27:55 +0000 (UTC) X-MXL-Hash: 5212478b50da35c4-52755124c9d8e6437e937495a103fd0c6f2b7803 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 28742125.0.6607877.00-258.18314351.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 19 Aug 2013 16:27:54 +0000 (UTC) X-MXL-Hash: 5212478a3d3e1ec4-72514dbc23e8e5bf5bf18c6b1757c1a57e8bdd45 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 r7JGRjtY027360; Mon, 19 Aug 2013 12:27:45 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7JGRTpw027001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 12:27:33 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 19 Aug 2013 16:27:16 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Mon, 19 Aug 2013 12:27:16 -0400 From: "PFAUTZ, PENN L" To: Michael Hammer , "Henning.Schulzrinne@fcc.gov" , "kent@bbn.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: Ac6c9Ozge0DbBLvpSRWm6Pzx5g4CWgAAX0KgAABtihA= Date: Mon, 19 Aug 2013 16:27:16 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D6049B4C7D@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=b8MFFK6x c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=flHPK6fBO6kA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=CPrZbrSYB2MA:10 a=48vgC7mUAAAA:8 a=HyQ2mm5JAAAA:8] X-AnalysisOut: [ a=yPCof4ZbAAAA:8 a=Gzg7IvrhhRcy6FKvUNMA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=iE9YWIBck50A:10 a=lZB815dzVvQA:10 a=VDw9KV-tx8oA:10 a] X-AnalysisOut: [=7DSvI1NPTFQA:10 a=tfWQ7tfFSBiQyx1_:21 a=eue8XKodBmT-oRUh:] X-AnalysisOut: [21] Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:28:22 -0000 Though I say this with some trepidation, it would seem easier to keep the t= wo together. At least in my world, service providers are the entities who k= now who a number is assigned to; they are the ultimate sources of CNAM data= even if their databases are not queried directly. Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Monday, August 19, 2013 12:14 PM To: Henning.Schulzrinne@fcc.gov; kent@bbn.com; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework) There is no reason that the digital signature binding a Name to a Number could not be orthogonal and managed independently from the valid sender/Number binding. You could bundle these together, but there may be reasons to keep them separate. With names, you are now talking about a registry with personal information and you may have many folks that do not want their names made public. I could see this as being more valuable for businesses, and that may be one or two orders of magnitude fewer entities to manage. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 19, 2013 12:02 PM To: 'Stephen Kent'; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) In general, given that many users base their decision on how to treat a cal= l on the textual caller ID, rather than the number, I think this is indeed a problem we should think about, even if the result is to punt this to anothe= r effort. As per Steve's comment, there is value of tying the provider of the name to the textual identifier, as it reduces the threat of DigiNotar-style attacks. I have a number of hypotheses: (1) Validating the names of commercial entities is more important than that of individuals. (Individuals also sometimes have legitimate reasons to provide partial information. For example, it's been a long tradition, whether justified by evidence or not, for households of single women to use initials rather than full first names in directory listings and thus also CLID.) The numbers shown to the public are likely public knowledge, so concerns about keeping them secret may be lower. (2) Legitimate businesses have an incentive to provide correct information that can be validated. The incentives of other parties are, shall we say, mixed. (3) Financial and other entities at significant risk of fraud are probably reasonably-well resourced and represented in databases such as the Dun&Bradstreet registry or government databases. (4) Whitelisting is easier than blacklisting. (5) It is helpful if name abusers can be located quickly, as that facilitates legal remedies. Thus, to get to the solution space, I can see three directions that might b= e productive: (1) Provide an indication by a trusted party (such as the terminating provider) as to the provenance of the textual callerID information. This will then allow other tools to provide, for example, some visual indication of the trustworthiness, without the provider having to make that editorial judgment. (2) Provide a whois-like mechanism for more extensive information at least equivalent to EV certs, possibly signed by the same key used for numbers, t= o prevent the CA issues. This would only be available to smartphones (but als= o case (1)) and is primarily meant to identify commercial identities. I see this as a separate effort; expect to hear more about this shortly. It needs to be cryptographically-coupled with the E.164 mechanism, even if provided by another party such as D&B. (3) For the SIP display-name case with end-to-end delivery, it would be helpful to have a way to sign both name and number. This doesn't deal with impostors or look-alike names, but other attacks outlined earlier. As number assignment goes beyond the realm of "few big companies with regulator visitors to the regulators" (in the FCC context, the "blue badge people"), we will face the same or similar whois-type issues that ICANN is dealing with. Fortunately, we have somewhat more local enforcement mechanisms, so the problem may be more tractable. As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chance= s that callees will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Monday, August 19, 2013 11:28 AM To: hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Hadriel, > ... > > We know we can't just trust callerid4u to claim any CNAM it wanted to. S= o let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). This aspect of your proposal already raises several concerns in my mind: - Jane Doe is not a globally unique name, so a called party can't assume that the caller is the Jane Doe that comes to mind - I strongly doubt that there is a single CA that could (should) be trusted to the identity of every caller in every country. if we have per-country CA= s we start getting close to the problems we have in the browser environment. - As a rule, the best CAs are ones that are authoritative for the attribute= s for which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally meaningful), and if one tries to tie both attributes into one cert ... My bottom line is that I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding. Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Mon Aug 19 09:42:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BE711E8288 for ; Mon, 19 Aug 2013 09:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1dVtZ+LiK7q for ; Mon, 19 Aug 2013 09:42:36 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id F033D11E8113 for ; Mon, 19 Aug 2013 09:42:32 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 19 Aug 2013 09:42:32 -0700 From: Michael Hammer To: "pp3129@att.com" , "Henning.Schulzrinne@fcc.gov" , "kent@bbn.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: Ac6c9Ozge0DbBLvpSRWm6Pzx5g4CWgAAX0KgAABtihAAALfrEA== Date: Mon, 19 Aug 2013 16:42:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2A668@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <38726EDA2109264987B45E29E758C4D6049B4C7D@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D6049B4C7D@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.107] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0089_01CE9CD9.91EC1E90" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:42:41 -0000 ------=_NextPart_000_0089_01CE9CD9.91EC1E90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Understand. I was mainly asking for the flexibility to manage them separately if need be. Be careful what you wish for. You just might get it. :) Mike -----Original Message----- From: PFAUTZ, PENN L [mailto:pp3129@att.com] Sent: Monday, August 19, 2013 12:27 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov; kent@bbn.com; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Though I say this with some trepidation, it would seem easier to keep the two together. At least in my world, service providers are the entities who know who a number is assigned to; they are the ultimate sources of CNAM data even if their databases are not queried directly. Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Monday, August 19, 2013 12:14 PM To: Henning.Schulzrinne@fcc.gov; kent@bbn.com; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) There is no reason that the digital signature binding a Name to a Number could not be orthogonal and managed independently from the valid sender/Number binding. You could bundle these together, but there may be reasons to keep them separate. With names, you are now talking about a registry with personal information and you may have many folks that do not want their names made public. I could see this as being more valuable for businesses, and that may be one or two orders of magnitude fewer entities to manage. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 19, 2013 12:02 PM To: 'Stephen Kent'; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) In general, given that many users base their decision on how to treat a call on the textual caller ID, rather than the number, I think this is indeed a problem we should think about, even if the result is to punt this to another effort. As per Steve's comment, there is value of tying the provider of the name to the textual identifier, as it reduces the threat of DigiNotar-style attacks. I have a number of hypotheses: (1) Validating the names of commercial entities is more important than that of individuals. (Individuals also sometimes have legitimate reasons to provide partial information. For example, it's been a long tradition, whether justified by evidence or not, for households of single women to use initials rather than full first names in directory listings and thus also CLID.) The numbers shown to the public are likely public knowledge, so concerns about keeping them secret may be lower. (2) Legitimate businesses have an incentive to provide correct information that can be validated. The incentives of other parties are, shall we say, mixed. (3) Financial and other entities at significant risk of fraud are probably reasonably-well resourced and represented in databases such as the Dun&Bradstreet registry or government databases. (4) Whitelisting is easier than blacklisting. (5) It is helpful if name abusers can be located quickly, as that facilitates legal remedies. Thus, to get to the solution space, I can see three directions that might be productive: (1) Provide an indication by a trusted party (such as the terminating provider) as to the provenance of the textual callerID information. This will then allow other tools to provide, for example, some visual indication of the trustworthiness, without the provider having to make that editorial judgment. (2) Provide a whois-like mechanism for more extensive information at least equivalent to EV certs, possibly signed by the same key used for numbers, to prevent the CA issues. This would only be available to smartphones (but also case (1)) and is primarily meant to identify commercial identities. I see this as a separate effort; expect to hear more about this shortly. It needs to be cryptographically-coupled with the E.164 mechanism, even if provided by another party such as D&B. (3) For the SIP display-name case with end-to-end delivery, it would be helpful to have a way to sign both name and number. This doesn't deal with impostors or look-alike names, but other attacks outlined earlier. As number assignment goes beyond the realm of "few big companies with regulator visitors to the regulators" (in the FCC context, the "blue badge people"), we will face the same or similar whois-type issues that ICANN is dealing with. Fortunately, we have somewhat more local enforcement mechanisms, so the problem may be more tractable. As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chances that callees will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Monday, August 19, 2013 11:28 AM To: hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Hadriel, > ... > > We know we can't just trust callerid4u to claim any CNAM it wanted to. > So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). This aspect of your proposal already raises several concerns in my mind: - Jane Doe is not a globally unique name, so a called party can't assume that the caller is the Jane Doe that comes to mind - I strongly doubt that there is a single CA that could (should) be trusted to the identity of every caller in every country. if we have per-country CAs we start getting close to the problems we have in the browser environment. - As a rule, the best CAs are ones that are authoritative for the attributes for which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally meaningful), and if one tries to tie both attributes into one cert ... My bottom line is that I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding. Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0089_01CE9CD9.91EC1E90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx OTE2NDIzMVowIwYJKoZIhvcNAQkEMRYEFCTEmNK4haBC8tcHPdllCq6Y38S8MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAIso13xjML3b1FM3GswmzmipdG22a5IUrsrIMdWB+ uLWZW9xG1DdfTJOSy7crMfup9IUhMUbkh73dLLMp2JCMGg6OLQ/dUjlSNTXyyPGprH0ObU1pOjBP 4UPJvasU2Ip+hau3AakdxqXpEhs/qa8HBQgMJteADGYgSrCqyEkO9f11SvHiIE35fWcciA4A+HHh t7kjBM2rv9gpl9KNz7igwVsCymsH2HJaQkpQAlcs67BBTObLevdbLHOTGmzrp2rE2tlgx4BkXypl 5THP+6z4kPUCNiFvIepfMYNYf4v/MXfZmz6a2uFJ4vbFMZiFccnubRES9zlxHRhGHrx8Z7ahHwAA AAAAAA== ------=_NextPart_000_0089_01CE9CD9.91EC1E90-- From hadriel.kaplan@oracle.com Mon Aug 19 09:46:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A129311E8127 for ; Mon, 19 Aug 2013 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeQb7eKR6KmL for ; Mon, 19 Aug 2013 09:46:40 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2C07721F9A96 for ; Mon, 19 Aug 2013 09:46:37 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JGkWCv020398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Aug 2013 16:46:33 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JGkUqN018519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 16:46:31 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JGkUeW027114; Mon, 19 Aug 2013 16:46:30 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Aug 2013 09:46:30 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 19 Aug 2013 12:46:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <706E0B71-B3C3-460C-9176-065E402EA2F6@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <5212397C.7000205@bbn.com> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Stephen Kent Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:46:47 -0000 He was talking about with regards to calling name. The web CA model has = issues because fundamentally the "trusted" CAs are not authoritative for = the names they assert - it's purely based on blind trust in the CA to be = correct. Worse even, there's no scope constraining what names they = could assert. With DANE, the "CA" is by definition authoritative for the name it = asserts, because DNS is the singular authority for domain names. And = even if you're an evil DNS operator the scope of your authority is = constrained to the domain names you're DNS-authoritative for, so you = can't create false name entries of others. For STIR calling numbers, we'll have the same constrained authority and = scope - whether it be as certificates or CIDER or whatever. For calling names, that's a much harder problem. The only true = authority for human names is national governments, and the authority for = business names is also national governments. (or state governments, as = is the case in the US) But no one's truly authoritative for a = phone-number-to-name mapping. The closest thing to such an authority is = the carriers themselves, but we've already conceded that some carriers = are either sloppy or complicit for source identity. For phone numbers = we can prevent such sloppiness/malevolence because we can know whether = the sender is actually authoritative for the phone number. But for the = calling name of the phone number...? -hadriel On Aug 19, 2013, at 12:11 PM, Brian Rosen wrote: > I'd like to examine your assertion "I don't believe in the web CA = model; it has failed. DANE is > a much better approach, becuase it aligns name space management and = public key binding." with respect to stir. >=20 > It seems inevitable that within a country, one entity will have the = data. If that isn't the case, then we're going to have long chains of = delegations that each would need to be validated. If there is one per = country, then there is only one signature per number. That is = independent of how credentials are stored. >=20 > Even if there were a small number of entities per country, that = wouldn't change much. >=20 > The point is that mistakes will be made and the DANE model, applied = here, when most records are under control of one or a small number of = entities, will be subject to the same issues that allowed the web CA = model to fail. What is attractive in DANE is that the DNS delegation is = diffuse, so compromise of one entity limits problems. We won't have = that situation. >=20 > I do think that the consequences of a mistake will be much more = modest. >=20 > Brian >=20 >=20 >=20 >=20 > On Mon, Aug 19, 2013 at 11:27 AM, Stephen Kent wrote: > Hadriel, >=20 >=20 > ... >=20 >=20 > We know we can't just trust callerid4u to claim any CNAM it wanted to. = So let's say instead of trusting callerid4u, we designated some common = CA to verify and sign CNAM information for everyone, and everyone has to = trust them. This CA used various sources of information and = verification to create a "certificate" that said "for this phone number = X, the user's name is Jane Doe", or maybe "for the holder of the private = key for this public key, the user's name is Jane Doe" (which is = basically what web certificates say). > This aspect of your proposal already raises several concerns in my = mind: >=20 > - Jane Doe is not a globally unique name, so a called party can't = assume that > the caller is the Jane Doe that comes to mind >=20 > - I strongly doubt that there is a single CA that could (should) be = trusted to > the identity of every caller in every country. if we have per-country > CAs we start getting close to the problems we have in the browser = environment. >=20 > - As a rule, the best CAs are ones that are authoritative for the = attributes for > which they vouch. For phone numbers a lot of folks seem confident that = we > have the right players to perform this function. For common names, we = do > not (until you add a lot of context, which is often not universally > meaningful), and if one tries to tie both attributes into one cert ... >=20 > My bottom line is that I don't believe in the web CA model; it has = failed. DANE is > a much better approach, becuase it aligns name space management and = public key binding. >=20 >=20 > Steve >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From Henning.Schulzrinne@fcc.gov Mon Aug 19 10:12:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF97C11E8130 for ; Mon, 19 Aug 2013 10:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIDgDD0XqKxp for ; Mon, 19 Aug 2013 10:12:48 -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 5C83B11E80DF for ; Mon, 19 Aug 2013 10:12:48 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' , Brian Rosen Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbCAAZhJ4IAAtYSAgAWUWwCAAAw6AIAACbcA///B60A= Date: Mon, 19 Aug 2013 17:12:47 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <5212397C.7000205@bbn.com> <706E0B71-B3C3-460C-9176-065E402EA2F6@oracle.com> In-Reply-To: <706E0B71-B3C3-460C-9176-065E402EA2F6@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Stephen Kent Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:12:53 -0000 As you note, there are third parties with accurate databases for incorporat= ed businesses, both government and private. If the corporate entity wants t= o, they can use the same public-private key pair to sign that information a= nd tie it to that phone number, assuming that the trusted third party gener= ally won't let just anyone do this. There is some impersonation risk while = most such records aren't connected to the STIR record, but I suspect the hi= gh-profile targets would most likely get their records signed and thus prev= ent shopping for the CA with the weakest security. The incentive to imperso= nate the local barber shop is probably low. An entity could simply list the outbound numbers in the third-party record = and provide a low level of assurance much better than today, as long as the= third party checks for duplicates. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Monday, August 19, 2013 12:46 PM To: Brian Rosen Cc: stir@ietf.org; Stephen Kent Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) He was talking about with regards to calling name. The web CA model has is= sues because fundamentally the "trusted" CAs are not authoritative for the = names they assert - it's purely based on blind trust in the CA to be correc= t. Worse even, there's no scope constraining what names they could assert. With DANE, the "CA" is by definition authoritative for the name it asserts,= because DNS is the singular authority for domain names. And even if you'r= e an evil DNS operator the scope of your authority is constrained to the do= main names you're DNS-authoritative for, so you can't create false name ent= ries of others. For STIR calling numbers, we'll have the same constrained authority and sco= pe - whether it be as certificates or CIDER or whatever. For calling names, that's a much harder problem. The only true authority f= or human names is national governments, and the authority for business name= s is also national governments. (or state governments, as is the case in th= e US) But no one's truly authoritative for a phone-number-to-name mapping.= The closest thing to such an authority is the carriers themselves, but we= 've already conceded that some carriers are either sloppy or complicit for = source identity. For phone numbers we can prevent such sloppiness/malevole= nce because we can know whether the sender is actually authoritative for th= e phone number. But for the calling name of the phone number...? -hadriel From richard@shockey.us Mon Aug 19 10:13:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4C311E829B for ; Mon, 19 Aug 2013 10:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.483 X-Spam-Level: X-Spam-Status: No, score=-101.483 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_81=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKfCVRpmmTJ4 for ; Mon, 19 Aug 2013 10:12:57 -0700 (PDT) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id F2C8C11E8282 for ; Mon, 19 Aug 2013 10:12:56 -0700 (PDT) Received: (qmail 28513 invoked by uid 0); 19 Aug 2013 17:12:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.mail.unifiedlayer.com with SMTP; 19 Aug 2013 17:12:31 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=slbVyjxnBpoetl+J1uXFajlV2QNpezshGIVMAkc10D8=; b=aqDZlt3iLCe+MhOJhHm3E+4+hC4Nzm5Hi3IiSwVh8Hy79aZkrN9hnPnCOEsSTHVoMltinbFin4/j8yhs7T6ant6LvreJS5sf/kDuaU0RBC/WJw0jMvMc2Lns8tRL9IFo; Received: from [71.114.100.16] (port=54136 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBT0I-0000vn-L1; Mon, 19 Aug 2013 11:12:30 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , , References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> Date: Mon, 19 Aug 2013 13:12:28 -0400 Message-ID: <012801ce9cff$491305a0$db3910e0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJoETO1yDlWf8bawuK/DoJvnQdzbQIrf0IYmFh9fjA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:13:02 -0000 Remember those databases are already in existence now. Phone companies and others have the data. A binding of number to "preferred display name" determined by the number holder as part of the service should be doable. How or if it is displayed is then the responsibility of the terminating SSP under appropriate national regulation. I agree with Henning here. "As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chances that callee will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information." It would also be nice if the UA could display something more than 15 ASCII characters, but that is a brand new issue STIR cannot, nor should it, solve. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Monday, August 19, 2013 12:14 PM To: Henning.Schulzrinne@fcc.gov; kent@bbn.com; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) There is no reason that the digital signature binding a Name to a Number could not be orthogonal and managed independently from the valid sender/Number binding. You could bundle these together, but there may be reasons to keep them separate. With names, you are now talking about a registry with personal information and you may have many folks that do not want their names made public. I could see this as being more valuable for businesses, and that may be one or two orders of magnitude fewer entities to manage. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 19, 2013 12:02 PM To: 'Stephen Kent'; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) In general, given that many users base their decision on how to treat a call on the textual caller ID, rather than the number, I think this is indeed a problem we should think about, even if the result is to punt this to another effort. As per Steve's comment, there is value of tying the provider of the name to the textual identifier, as it reduces the threat of DigiNotar-style attacks. I have a number of hypotheses: (1) Validating the names of commercial entities is more important than that of individuals. (Individuals also sometimes have legitimate reasons to provide partial information. For example, it's been a long tradition, whether justified by evidence or not, for households of single women to use initials rather than full first names in directory listings and thus also CLID.) The numbers shown to the public are likely public knowledge, so concerns about keeping them secret may be lower. (2) Legitimate businesses have an incentive to provide correct information that can be validated. The incentives of other parties are, shall we say, mixed. (3) Financial and other entities at significant risk of fraud are probably reasonably-well resourced and represented in databases such as the Dun&Bradstreet registry or government databases. (4) Whitelisting is easier than blacklisting. (5) It is helpful if name abusers can be located quickly, as that facilitates legal remedies. Thus, to get to the solution space, I can see three directions that might be productive: (1) Provide an indication by a trusted party (such as the terminating provider) as to the provenance of the textual callerID information. This will then allow other tools to provide, for example, some visual indication of the trustworthiness, without the provider having to make that editorial judgment. (2) Provide a whois-like mechanism for more extensive information at least equivalent to EV certs, possibly signed by the same key used for numbers, to prevent the CA issues. This would only be available to smartphones (but also case (1)) and is primarily meant to identify commercial identities. I see this as a separate effort; expect to hear more about this shortly. It needs to be cryptographically-coupled with the E.164 mechanism, even if provided by another party such as D&B. (3) For the SIP display-name case with end-to-end delivery, it would be helpful to have a way to sign both name and number. This doesn't deal with impostors or look-alike names, but other attacks outlined earlier. As number assignment goes beyond the realm of "few big companies with regulator visitors to the regulators" (in the FCC context, the "blue badge people"), we will face the same or similar whois-type issues that ICANN is dealing with. Fortunately, we have somewhat more local enforcement mechanisms, so the problem may be more tractable. As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chances that callees will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Monday, August 19, 2013 11:28 AM To: hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Hadriel, > ... > > We know we can't just trust callerid4u to claim any CNAM it wanted to. > So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). This aspect of your proposal already raises several concerns in my mind: - Jane Doe is not a globally unique name, so a called party can't assume that the caller is the Jane Doe that comes to mind - I strongly doubt that there is a single CA that could (should) be trusted to the identity of every caller in every country. if we have per-country CAs we start getting close to the problems we have in the browser environment. - As a rule, the best CAs are ones that are authoritative for the attributes for which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally meaningful), and if one tries to tie both attributes into one cert ... My bottom line is that I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding. Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Mon Aug 19 10:25:21 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E64811E82D3 for ; Mon, 19 Aug 2013 10:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYQ3yf3kNjc1 for ; Mon, 19 Aug 2013 10:25: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 5C30511E82CA for ; Mon, 19 Aug 2013 10:25:10 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'Dwight, Timothy M (Tim)'" , Hadriel Kaplan Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbCAAZhJ4IAAtYSAgAAwhgCAAGoAgIAAIfKAgASzCVA= Date: Mon, 19 Aug 2013 17:25:08 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3012ADB3A3E@FHDP1LUMXC7V31.us.one.verizon.! ! com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:25:21 -0000 I see no reason not to have either the service provider or a third party pr= ovide this information. In some cases, important information (e.g., the hol= ding of licenses or business permits) is only readily available via third p= arties. I don't think the local phone company wants to validate whether the= lawyer is admitted to the bar, the doctor, charity or driveway sealer are = state-licensed and the bank is FDIC-insured, but all of these are at least = as important as the plain name to reduce fraud. Such additional indications= make look-alike impersonation much less likely, i.e., where the perp uses = "Bank for America" or typos to fool the quick glance. However, generally, trusted entities tend to be somewhat larger and few. It= is unlikely that a diligent rural ILEC or CLEC will ever accrue enough rec= ognition to be on the "known diligent" list. You then either end up with a = browser-like mechanism of endowing certain gatekeepers with a seal of appro= val, or you can at least separate the two functions, where needed. The smal= l rural ILEC may decide that it's better to let the Chamber of Commerce or = the state corporation board do this. Verizon and kin, on the other hand, ma= y well want to acquire a reputation of validating their customer identities= . Thus, my suggestion to allow for both originating service provider and thir= d-party models. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwi= ght, Timothy M (Tim) Sent: Friday, August 16, 2013 9:30 AM To: Hadriel Kaplan Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) The ability to "cross-check" or otherwise validate the contents of a databa= se, is not unique to "3rd parties". It baffles me why involving a 3rd part= y would be expected to make things better. AFAICS the service provider and= the 3rd party are equally capable of being vigilent with respect to the co= ntent of their database; but the service provider is uniquely positioned by= virtue of his ongoing business relationship with the calling party. That = relationship gives him greater access to information about the customer's i= dentity, and more incentive to manage it properly, than a 3rd party would h= ave. That doesn't eliminate the potential for "dodgy" service providers. Obviou= sly. But 3rd party database providers have the same potential to be "dodgy= ", and less incentive not to be. I wish that last comment were true, but I don't think it is. The problem i= s that "dodgy" entities typically interconnect to the PSTN via wholesale se= rvices provided by a "traditional" carrier. To exchange traffic with them = you go through their wholesale provider. Even if A and B directly intercon= nect, and neither is the least bit "dodgy", there may be sitting behind one= or both of them, carriers that are. Even if A and B trust one another com= pletely I think they would still want to be protected from one anothers' wh= olesale customers. And besides, in business nobody ever trusts anybody com= pletely :-). tim -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, August 16, 2013 6:29 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) So what that says to me is you can't trust a CA - or at least not all the "= CAs". I've been told that some CNAM DB providers don't just blindly believ= e LIDB entries, but actually perform cross-reference checking with other da= ta. (if they even populated the data from LIDB to begin with) But that's one of the reasons it feels logical to me to keep it in a separa= te 3rd-party database, because you can't just trust what comes in on SIP/SS= 7 - you need a third party to perform some verification/cross-checking of t= he data, and in-advance as opposed to just when the call comes in. (BTW, this is not the case for direct VoIP interconnection of call originat= or and terminator - for that you don't need STIR nor 3rd party CNAM databas= es) -hadriel On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" wrote: > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers can a= nd do run their own LIDBs. As do all sorts of 3rd parties, who get informa= tion from God-only-knows where, about individuals with whom they have no bu= siness relationship (so, no incentive to "keep happy"). > > Providing a validated calling number would not protect my mom from a scam= mer who's got a number from such a "dodgy" carrier, and has been allowed by= that carrier to associate with it the name of her bank. AFAICT it only he= lps entities that operate their own identity database, e.g., LEAs and PSAPs= . > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 15, 2013 9:16 PM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > Charter) > > > I may be misunderstanding you, but I think we're kind of getting a soluti= on to that... though maybe not in a way that people want. > > For sake of argument, let's ignore the technology or any proposed solutio= n for STIR, or even STIR in general. Also ignore the existing CNAM busines= s model and pretend we wanted to provide CNAM for the first time, from scra= tch. > > We know we can't just trust callerid4u to claim any CNAM it wanted to. S= o let's say instead of trusting callerid4u, we designated some common CA to= verify and sign CNAM information for everyone, and everyone has to trust t= hem. This CA used various sources of information and verification to creat= e a "certificate" that said "for this phone number X, the user's name is Ja= ne Doe", or maybe "for the holder of the private key for this public key, t= he user's name is Jane Doe" (which is basically what web certificates say). > > So then we look at how to put this into SIP, and instead of putting the w= hole certificate in the INVITE, we use an external database lookup mechanis= m. That's basically STIR, for the phone number part. And the existing CNA= M databases are basically the "CA", where they provide a trusted lookup dat= abase of phone-number -> CNAM. Since STIR validates the phone number, the = CNAM database lookup should be valid... assuming you trust the CNAM databas= e to be valid to begin with. But if you *don't* trust it, it's not clear w= hy you'd trust any other CA either. > > So we already have (or will once we have STIR) a way to get a fairly vali= d CNAM, if you believe in a CA model for that. What we don't have is a dif= ferent pricing/business model for how the "CA" charges for retrieving the "= certificate" data. But I don't think it's the technology that causes this = really, so it's not something we can fix here. I mean even web CAs charge = an impressive amount of money for web certificates, and the technology part= of the job is trivial for them, afaik. They charge what they believe the = market will bear. > > -hadriel > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" wrote: > >> With respect, I think statements like " I don't see how signing helps " = put the cart before the horse. Signing is an attribute of a possible solut= ion, not a requirement. >> >> It is precisely the www.callerid4u.com scenario you note, that worries m= e. ISTM that if we declare any sort of validation for calling name to be o= ut of scope, we provide no solution to the victims of scams enabled by serv= ices that allow dishonest actors to associate the name of a bank with their= phone number. >> >> I recognize that names are not delegated in the same way that numbers ar= e, and that there are all sorts of semantic nuances that make their validat= ion difficult. Still, CA's do it. And it's been proposed on this list tha= t a smartphone app could do it. So I don't see why we're so quick to agree= we can't do it. Or at least, do something. >> >> I'm a pragmatist. Maybe we can't do as good a job validating names as w= e can numbers. I still think it's better to make things better than to do = nothing. For example ISTM it'd be positive progress to enable the called p= arty to make a more informed decision about whether to trust the calling na= me, than he can today. >> >> tim >> >> p.s. I tend to agree with Rich, that we can't forever duck the issue of = what gets presented to the called party. Whether it's addressed directly o= r not, we're already making assumptions about what is and isn't reasonable. >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Henning Schulzrinne >> Sent: Wednesday, August 14, 2013 2:19 PM >> To: 'Paul Kyzivat'; Brian Rosen >> Cc: stir@ietf.org >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> Just piling on... There are at least three levels of information here, m= aking it difficult to do that within the signaling framework: >> >> * the name of the person calling (vs. the subscriber name) >> * the name of the organization >> * properties of the organization ("licensed plumber", "FDIC-insured=20 >> bank", "located in Washington, DC", "registered charity") >> >> This is more whois-like information than just the SIP display name. In t= he certificate space, we have two levels: (1) assertion of domain name cont= rol; (2) EV (extended validation) certs. It would be interesting to see how= well the EV concept has worked out in practice. >> >> I don't see how signing helps here at all, for the reasons mentioned. Ne= farious actors can use services such as http://www.callerid4u.com/ to use a= legitimate number with just about any name string. And for corporate accou= nts, the service provider has no way of knowing whether Tom Sawyer is reall= y at a particular number in a range and whether that entity prefers to list= the name of the person, just the organization, the location ("PizzaHut Leo= nia") or something else. Indeed, the same number can legitimately have mult= iple display names that change quickly over time (e.g., staff at the doctor= 's office). >> >> Verifiable whois-like information could be very useful and service provi= ders could see that as an opportunity, given that they do know a lot about = their customers, such as their billing and service address and how long the= y have been in business. But it's a separate problem, probably more closely= related to the number allocation problem. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Paul Kyzivat >> Sent: Wednesday, August 14, 2013 3:04 PM >> To: Brian Rosen >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ,=20 >> PENN L >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to >> Charter) >> >> On 8/14/13 8:38 PM, Brian Rosen wrote: >>> I suppose it's possible, but what is the criteria for validation? >>> >>> With TNs, we have credentials that accompany number delegation - we=20 >>> have a clear path to assuring that the caller asserting the identity=20 >>> is indeed entitled to claim control of that number (well, SPs=20 >>> mostly, not the caller, at least initially). There is no equivalent=20 >>> assurance for CNAM. >>> >>> I don't want to get into a fight over which database is better, but=20 >>> the alternate, doesn't depend on the origination carrier mechansism=20 >>> is statisically actually a better "validation" of the content than=20 >>> what a traditional carrier gets in his service order (because they=20 >>> usually don't actually validate the content), and is infiniately=20 >>> better than the carriers that allow the consumer to put anything=20 >>> they want in the database. Without a reasonable way to assure that=20 >>> the database is actually valid, what is the value of carrying an assert= ion? >> >> While I recognize that letting the customer put in whatever they want=20 >> is problematic, I have no idea whether the alternative of letting the=20 >> CNAM provider include whatever they want is "better". (How would we=20 >> measure >> that?) >> >> (I've just been trying to deal with an "information aggregator" that=20 >> is publishing wrong information about me and won't change it. So I'm=20 >> not feeling good about that sort of thing.) >> >> ISTM that is is yet another example of ancient, informal, manual=20 >> systems, that once mostly "worked" based on the good will of the=20 >> people involved, but that have now been automated into monstrosities=20 >> that nobody understands. (Management of healthcare data is another >> example.) >> >> Ultimately there will need to be a big effort to develop a formal framew= ork for this. And it will probably require the creation of new laws. >> >> Alternatively this could be left to the open market. (E.g., The=20 >> callee could just Google the calling number.) >> >> In any case STIR can't go down this rat hole. >> >> Thanks, >> Paul >> >>> If we had such a mechanism, what prevents one of the carriers that=20 >>> let's you put anything you want in the database from asserting that=20 >>> the content of P-A-ID is valid, when the user is allowed to say=20 >>> whatever they want goes in P-A-ID? >>> >>> The best thing I can come up with would be to have some independent=20 >>> validation service that used other data sources to validate the=20 >>> content, and let them sign it. Then we could carry that signature some= where. >>> >>> Right now, I think we should leave it out of scope. If we can=20 >>> figure out a way to do validation, then we can revisit the notion of=20 >>> carrying evidence of validation in future work. >>> >>> Does argue for making sure that whatever mechanism we arrive at=20 >>> should have some obvious extension mechanism, perhaps along the=20 >>> lines of what Jon was suggesting for media properties. If you=20 >>> recall, he proposed to have a digest of SDP where the digest was=20 >>> protected by the signature, but if the SDP received didn't match the=20 >>> SDP sent, the termination side could know that, but the basic=20 >>> identity mechanism could succeed anyway (that is, you knew you had a va= lid identity and a modified SDP). >>> >>> Brian >>> >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: >>> >>> Would it be possible to provide an indication of whether the calling >>> name was validated (in the same sense that the calling number was >>> validated, but an independent indication)?____ >>> >>> __ __ >>> >>> ISTM that should be a simple exercise, protocol-wise. And it >>> maintains the parallel treatment of name and number that we have >>> today (e.g., there are today separate indications of privacy, for >>> name and number). But that's not my main concern; mostly I'm >>> thinking of the evolution of the process by which calling name is >>> provided. Even if it's not possible to validate calling name as >>> provided by CNAM, it might be possible to validate calling name as >>> provided by other methods; e.g., by the calling network in the >>> display-name header field in the FROM or (more likely in public >>> networks) the P-A-ID header.____ >>> >>> __ __ >>> >>> tim____ >>> >>> __ __ >>> >>> __ __ >>> >>> *From:*stir-bounces@ietf.org >> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org >>> ] *On Behalf Of >>> *PFAUTZ, PENN L >>> *Sent:* Wednesday, August 14, 2013 9:37 AM >>> *To:* Brian Rosen; Hadriel Kaplan >>> *Cc:* stir@ietf.org ; >>> Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I assume the concern in this thread is with the case where a number >>> might be authenticated but the CNAM displayed would be misleading >>> because of lax policies of the CNAM provider - e.g., the bad guy >>> makes a call from what is indeed his legit number but has managed to >>> get Bank of America into his CNAM entry.____ >>> >>> __ __ >>> >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far >>> for stir. Leave what happens after the number is validated up to >>> national authorities since arrangements may differ. And at least in >>> the case above it should be possible to trace back to the=20 >>> perp.____ >>> >>> __ __ >>> >>> More generally I think the object of stir ought to be just to >>> provide the customer an indication of whether the calling number was >>> validated on not - whether calls get blocked or unvalidated numbers >>> are still displayed should be up to the customer and their service >>> provider.____ >>> >>> __ __ >>> >>> Penn Pfautz____ >>> >>> AT&T Access Management____ >>> >>> +1-732-420-4962____ >>> >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On >>> Behalf Of *Brian Rosen >>> *Sent:* Wednesday, August 14, 2013 9:32 AM >>> *To:* Hadriel Kaplan >>> *Cc:* stir@ietf.org; Paul Kyzivat >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to >>> Charter)____ >>> >>> __ __ >>> >>> I think we probably should keep CNAM out of this for now=20 >>> anyway.____ >>> >>> __ __ >>> >>> The advantage of the credential delegation process as we have >>> defined it is that it's authoritative.____ >>> >>> __ __ >>> >>> The current CNAM databases cannot be called "authoritative" really. >>> Classically, as you describe, there is a database operated by on >>> on behalf of the origination carrier and queried by the termination >>> carrier (often with a charge to query). The content is what the >>> carrier has recorde from the original service order, but there isn't >>> any attempt to validate those names, and there are carriers who will >>> let you put anything you like in there. How "authoritative" is >>> that? Then there are other databases, like Neustar's, that don't >>> have any relationship to the originination carrier - the termination >>> carrier dips an independently developed database of name-number >>> relationships. These databases are developed using a wide variety >>> of sources and have evolved to be very accurate, but hardly >>> "authoritative".____ >>> >>> __ __ >>> >>> And yes, Hadriel, there are regulatory restrictions, mostly about >>> what the NPAC (number portability database administrator) can do. >>> The CNAM databases have very few regulations to deal with.____ >>> >>> __ __ >>> >>> Brian ____ >>> >>> >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>> >>> >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From kent@bbn.com Mon Aug 19 10:52:55 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33F011E8282 for ; Mon, 19 Aug 2013 10:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuTMidT-XOV9 for ; Mon, 19 Aug 2013 10:52:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 057A111E8125 for ; Mon, 19 Aug 2013 10:52:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45278 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBTcu-000EZM-Vo; Mon, 19 Aug 2013 13:52:25 -0400 Message-ID: <52125B57.6040808@bbn.com> Date: Mon, 19 Aug 2013 13:52:23 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <5212397C.7000205@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070303070703000008010604" Cc: "stir@ietf.org" , "hadriel.kaplan@oracle.com" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:52:56 -0000 This is a multi-part message in MIME format. --------------070303070703000008010604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > I'd like to examine your assertion "I don't believe in the web CA > model; it has failed. DANE is > a much better approach, becuase it aligns name space management and > public key binding." with respect to stir. sure. > It seems inevitable that within a country, one entity will have the > data. If that isn't the case, then we're going to have long chains of > delegations that each would need to be validated. If there is one per > country, then there is only one signature per number. That is > independent of how credentials are stored. If we're talking about phone numbers, I agree and don't see a problem. if we're talking about names, I do. Also, I didn't discuss multiple signatures for any credential. > Even if there were a small number of entities per country, that > wouldn't change much. again, for phone numbers I don't see a problem. > The point is that mistakes will be made and the DANE model, applied > here, when most records are under control of one or a small number of > entities, will be subject to the same issues that allowed the web CA > model to fail. What is attractive in DANE is that the DNS delegation > is diffuse, so compromise of one entity limits problems. We won't > have that situation. I would phrase your last comment very differently. The DANE model is attractive because it limits what any entity can assert (and have recognized as legitimate) based on that entity's location in the DNS hierarchy. It also has the property I mentioned, i.e., the relationship between the vouched for data and the management entity is the obvious one. Also, I am not suggesting use of DANE here, per se; I am using it as an example. There are a few examples I employ when discussing this sort of issue. For example, passports and employee ID cards. Most folks agree that each country is authoritative as the issuer of passports for its citizens, identifying individuals based on a name, passport #, and nationality. (There are a very few exceptions, but not enough to merit further discussion.) Similarly, most folks seem to agree that a company is authoritative as the issuer of ID cards for employees, identifying them by name and employee ID number. Whenever we stray from simple models of issuing credentials based on authoritative databases, bad things happen. Steve --------------070303070703000008010604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

I'd like to examine your assertion "I don't believe in the web CA model; it has failed. DANE is
a much better approach, becuase it aligns name space management and public key binding." with respect to stir.
sure.
It seems inevitable that within a country, one entity will have the data.  If that isn't the case, then we're going to have long chains of delegations that each would need to be validated.  If there is one per country, then there is only one signature per number.  That is independent of how credentials are stored.
If we're talking about phone numbers, I agree and don't see a problem. if we're talking
about names, I do. Also, I didn't discuss multiple signatures for any credential.
Even if there were a small number of entities per country, that wouldn't change much.
again, for phone numbers I don't see a problem.
The point is that mistakes will be made and the DANE model, applied here, when most records are under control of one or  a small number of entities, will be subject to the same issues that allowed the web CA model to fail.  What is attractive in DANE is that the DNS delegation is diffuse, so compromise of one entity limits problems.  We won't have that situation.
I would phrase your last comment very differently. The DANE model is attractive because it limits what any
entity can assert (and have recognized as legitimate) based on that entity's location in the DNS hierarchy. It also
has the property I mentioned, i.e., the relationship between the vouched for data and the management entity
is the obvious one. Also, I am not suggesting use of DANE here, per se; I am using it as an example.

There are a few  examples I employ when discussing this sort of issue. For example, passports and employee ID cards.
Most folks agree that each country is authoritative as the issuer of passports for its citizens, identifying individuals based
on a name, passport #, and nationality. (There are a very few exceptions, but not enough to merit further discussion.)
Similarly, most folks seem to agree that a company is authoritative as the issuer of ID cards for employees, identifying
them by name and employee ID number. Whenever we stray from simple models of issuing credentials based on authoritative
databases, bad things happen.

Steve
--------------070303070703000008010604-- From br@brianrosen.net Mon Aug 19 10:55:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4C121F8B12 for ; Mon, 19 Aug 2013 10:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.601 X-Spam-Level: X-Spam-Status: No, score=-100.601 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj5ieDzzEBQa for ; Mon, 19 Aug 2013 10:55:45 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 524B511E823D for ; Mon, 19 Aug 2013 10:55:45 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p10so5537346pdj.4 for ; Mon, 19 Aug 2013 10:55:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IH0aG9x494AWn+hz8vQ54FqNIr+iFiOVD/s/LXctD4s=; b=Xah2zwYD2sMpXgG7h5IweBvtken8s9O6fDddAraiQVx8ApFFZCgKkA11OgjzN/qbEL D8Gc68YwCh+6o2q/J2KVW+WR4BntSYvSaK9xWqseUak60ARbqboXFDbWy7lV/hnCf5uN 5q5OS2Ju4yzlKKP+h/NQLSAjPzFrFPNJqpQhLS15cZx3l4vKS5EkjcdRN4H/Nlq5YnPr Polkz2Sp/0t2g/qDII1Mzyv+xuqFW3vpvkBm6una4HW4Thfa1pVhqmhd+mQH++0qf8ml yu0GqYvKDLCSZ/KKpVhr3fdrZgY98zpsJBzyI9yh27otpDPp/xw8tsaZyRSGQ0SxEwZX ZINg== X-Gm-Message-State: ALoCoQklVJL59me54J/63CuaJMn21Ktw3GBHl95rrjwIC0ohkQIwoJ8BFTVov6hb/R0IoP4BNjw4 MIME-Version: 1.0 X-Received: by 10.66.218.98 with SMTP id pf2mr4460120pac.120.1376934945071; Mon, 19 Aug 2013 10:55:45 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Mon, 19 Aug 2013 10:55:44 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> Date: Mon, 19 Aug 2013 13:55:44 -0400 Message-ID: From: Brian Rosen To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=047d7b5db1b047bc1d04e450a64e Cc: "stir@ietf.org List" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:55:50 -0000 --047d7b5db1b047bc1d04e450a64e Content-Type: text/plain; charset=ISO-8859-1 There are accurate databases for human names in most developed countries. Further, the databases you refer to would not have the information needed to associate a business name with all of the numbers that the business might use. There are databases that have much of the information, but would likely need some enhancement to have ALL of the possible numbers. The issue I think we need to deal with has two aspects: 1. The entity asserting the name can't really claim authority because there is no delegation chain for "John Smith" or "World Wide Widgets". There are third parties that can assert some level of assurance that the name goes with the number. 2. The assurance you get is not binary. There is a score. So, I think the way this would work is that a third party asserts a likelihood score that the name asserted in the signaling is valid. This would work the best if the originating service provider asserted the score. The reason why is that the score is better the more information is known. If the originating SP provides the assurance service information like service address, or other identifying information, the confidence is better, and the score can be higher. If there are only a few assurance services, their credentials could be known by the terminating end, and some form of the score signed by the service could be attached to the call and verified at the termination. The terminating end could use an assurance service of its own choosing, but it would likely have only the name and number as input, and thus have a limited score range to work with. I do think that if there was a notion of a category (bank, insurance company, doctor) included in the data, possibly with its own score, that would help. I think this is outside the charter. We can either decide to work on this later here in stir, or start a parallel effort. Brian On Mon, Aug 19, 2013 at 1:25 PM, Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> wrote: > I see no reason not to have either the service provider or a third party > provide this information. In some cases, important information (e.g., the > holding of licenses or business permits) is only readily available via > third parties. I don't think the local phone company wants to validate > whether the lawyer is admitted to the bar, the doctor, charity or driveway > sealer are state-licensed and the bank is FDIC-insured, but all of these > are at least as important as the plain name to reduce fraud. Such > additional indications make look-alike impersonation much less likely, > i.e., where the perp uses "Bank for America" or typos to fool the quick > glance. > > However, generally, trusted entities tend to be somewhat larger and few. > It is unlikely that a diligent rural ILEC or CLEC will ever accrue enough > recognition to be on the "known diligent" list. You then either end up with > a browser-like mechanism of endowing certain gatekeepers with a seal of > approval, or you can at least separate the two functions, where needed. The > small rural ILEC may decide that it's better to let the Chamber of Commerce > or the state corporation board do this. Verizon and kin, on the other hand, > may well want to acquire a reputation of validating their customer > identities. > > Thus, my suggestion to allow for both originating service provider and > third-party models. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Dwight, Timothy M (Tim) > Sent: Friday, August 16, 2013 9:30 AM > To: Hadriel Kaplan > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > The ability to "cross-check" or otherwise validate the contents of a > database, is not unique to "3rd parties". It baffles me why involving a > 3rd party would be expected to make things better. AFAICS the service > provider and the 3rd party are equally capable of being vigilent with > respect to the content of their database; but the service provider is > uniquely positioned by virtue of his ongoing business relationship with the > calling party. That relationship gives him greater access to information > about the customer's identity, and more incentive to manage it properly, > than a 3rd party would have. > > That doesn't eliminate the potential for "dodgy" service providers. > Obviously. But 3rd party database providers have the same potential to be > "dodgy", and less incentive not to be. > > I wish that last comment were true, but I don't think it is. The problem > is that "dodgy" entities typically interconnect to the PSTN via wholesale > services provided by a "traditional" carrier. To exchange traffic with > them you go through their wholesale provider. Even if A and B directly > interconnect, and neither is the least bit "dodgy", there may be sitting > behind one or both of them, carriers that are. Even if A and B trust one > another completely I think they would still want to be protected from one > anothers' wholesale customers. And besides, in business nobody ever trusts > anybody completely :-). > > tim > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Friday, August 16, 2013 6:29 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > > So what that says to me is you can't trust a CA - or at least not all the > "CAs". I've been told that some CNAM DB providers don't just blindly > believe LIDB entries, but actually perform cross-reference checking with > other data. (if they even populated the data from LIDB to begin with) > > But that's one of the reasons it feels logical to me to keep it in a > separate 3rd-party database, because you can't just trust what comes in on > SIP/SS7 - you need a third party to perform some > verification/cross-checking of the data, and in-advance as opposed to just > when the call comes in. > > (BTW, this is not the case for direct VoIP interconnection of call > originator and terminator - for that you don't need STIR nor 3rd party CNAM > databases) > > -hadriel > > > On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" < > timothy.dwight@verizon.com> wrote: > > > The problem is the CNAM lookup isn't trustworthy. "dodgy" carriers can > and do run their own LIDBs. As do all sorts of 3rd parties, who get > information from God-only-knows where, about individuals with whom they > have no business relationship (so, no incentive to "keep happy"). > > > > Providing a validated calling number would not protect my mom from a > scammer who's got a number from such a "dodgy" carrier, and has been > allowed by that carrier to associate with it the name of her bank. AFAICT > it only helps entities that operate their own identity database, e.g., LEAs > and PSAPs. > > > > tim > > > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > > Sent: Thursday, August 15, 2013 9:16 PM > > To: Dwight, Timothy M (Tim) > > Cc: stir@ietf.org List > > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > > Charter) > > > > > > I may be misunderstanding you, but I think we're kind of getting a > solution to that... though maybe not in a way that people want. > > > > For sake of argument, let's ignore the technology or any proposed > solution for STIR, or even STIR in general. Also ignore the existing CNAM > business model and pretend we wanted to provide CNAM for the first time, > from scratch. > > > > We know we can't just trust callerid4u to claim any CNAM it wanted to. > So let's say instead of trusting callerid4u, we designated some common CA > to verify and sign CNAM information for everyone, and everyone has to trust > them. This CA used various sources of information and verification to > create a "certificate" that said "for this phone number X, the user's name > is Jane Doe", or maybe "for the holder of the private key for this public > key, the user's name is Jane Doe" (which is basically what web certificates > say). > > > > So then we look at how to put this into SIP, and instead of putting the > whole certificate in the INVITE, we use an external database lookup > mechanism. That's basically STIR, for the phone number part. And the > existing CNAM databases are basically the "CA", where they provide a > trusted lookup database of phone-number -> CNAM. Since STIR validates the > phone number, the CNAM database lookup should be valid... assuming you > trust the CNAM database to be valid to begin with. But if you *don't* > trust it, it's not clear why you'd trust any other CA either. > > > > So we already have (or will once we have STIR) a way to get a fairly > valid CNAM, if you believe in a CA model for that. What we don't have is a > different pricing/business model for how the "CA" charges for retrieving > the "certificate" data. But I don't think it's the technology that causes > this really, so it's not something we can fix here. I mean even web CAs > charge an impressive amount of money for web certificates, and the > technology part of the job is trivial for them, afaik. They charge what > they believe the market will bear. > > > > -hadriel > > > > > > On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" < > timothy.dwight@verizon.com> wrote: > > > >> With respect, I think statements like " I don't see how signing helps " > put the cart before the horse. Signing is an attribute of a possible > solution, not a requirement. > >> > >> It is precisely the www.callerid4u.com scenario you note, that worries > me. ISTM that if we declare any sort of validation for calling name to be > out of scope, we provide no solution to the victims of scams enabled by > services that allow dishonest actors to associate the name of a bank with > their phone number. > >> > >> I recognize that names are not delegated in the same way that numbers > are, and that there are all sorts of semantic nuances that make their > validation difficult. Still, CA's do it. And it's been proposed on this > list that a smartphone app could do it. So I don't see why we're so quick > to agree we can't do it. Or at least, do something. > >> > >> I'm a pragmatist. Maybe we can't do as good a job validating names as > we can numbers. I still think it's better to make things better than to do > nothing. For example ISTM it'd be positive progress to enable the called > party to make a more informed decision about whether to trust the calling > name, than he can today. > >> > >> tim > >> > >> p.s. I tend to agree with Rich, that we can't forever duck the issue of > what gets presented to the called party. Whether it's addressed directly > or not, we're already making assumptions about what is and isn't reasonable. > >> > >> > >> -----Original Message----- > >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > >> Of Henning Schulzrinne > >> Sent: Wednesday, August 14, 2013 2:19 PM > >> To: 'Paul Kyzivat'; Brian Rosen > >> Cc: stir@ietf.org > >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > >> Charter) > >> > >> Just piling on... There are at least three levels of information here, > making it difficult to do that within the signaling framework: > >> > >> * the name of the person calling (vs. the subscriber name) > >> * the name of the organization > >> * properties of the organization ("licensed plumber", "FDIC-insured > >> bank", "located in Washington, DC", "registered charity") > >> > >> This is more whois-like information than just the SIP display name. In > the certificate space, we have two levels: (1) assertion of domain name > control; (2) EV (extended validation) certs. It would be interesting to see > how well the EV concept has worked out in practice. > >> > >> I don't see how signing helps here at all, for the reasons mentioned. > Nefarious actors can use services such as http://www.callerid4u.com/ to > use a legitimate number with just about any name string. And for corporate > accounts, the service provider has no way of knowing whether Tom Sawyer is > really at a particular number in a range and whether that entity prefers to > list the name of the person, just the organization, the location ("PizzaHut > Leonia") or something else. Indeed, the same number can legitimately have > multiple display names that change quickly over time (e.g., staff at the > doctor's office). > >> > >> Verifiable whois-like information could be very useful and service > providers could see that as an opportunity, given that they do know a lot > about their customers, such as their billing and service address and how > long they have been in business. But it's a separate problem, probably more > closely related to the number allocation problem. > >> > >> -----Original Message----- > >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Wednesday, August 14, 2013 3:04 PM > >> To: Brian Rosen > >> Cc: stir@ietf.org; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, > >> PENN L > >> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to > >> Charter) > >> > >> On 8/14/13 8:38 PM, Brian Rosen wrote: > >>> I suppose it's possible, but what is the criteria for validation? > >>> > >>> With TNs, we have credentials that accompany number delegation - we > >>> have a clear path to assuring that the caller asserting the identity > >>> is indeed entitled to claim control of that number (well, SPs > >>> mostly, not the caller, at least initially). There is no equivalent > >>> assurance for CNAM. > >>> > >>> I don't want to get into a fight over which database is better, but > >>> the alternate, doesn't depend on the origination carrier mechansism > >>> is statisically actually a better "validation" of the content than > >>> what a traditional carrier gets in his service order (because they > >>> usually don't actually validate the content), and is infiniately > >>> better than the carriers that allow the consumer to put anything > >>> they want in the database. Without a reasonable way to assure that > >>> the database is actually valid, what is the value of carrying an > assertion? > >> > >> While I recognize that letting the customer put in whatever they want > >> is problematic, I have no idea whether the alternative of letting the > >> CNAM provider include whatever they want is "better". (How would we > >> measure > >> that?) > >> > >> (I've just been trying to deal with an "information aggregator" that > >> is publishing wrong information about me and won't change it. So I'm > >> not feeling good about that sort of thing.) > >> > >> ISTM that is is yet another example of ancient, informal, manual > >> systems, that once mostly "worked" based on the good will of the > >> people involved, but that have now been automated into monstrosities > >> that nobody understands. (Management of healthcare data is another > >> example.) > >> > >> Ultimately there will need to be a big effort to develop a formal > framework for this. And it will probably require the creation of new laws. > >> > >> Alternatively this could be left to the open market. (E.g., The > >> callee could just Google the calling number.) > >> > >> In any case STIR can't go down this rat hole. > >> > >> Thanks, > >> Paul > >> > >>> If we had such a mechanism, what prevents one of the carriers that > >>> let's you put anything you want in the database from asserting that > >>> the content of P-A-ID is valid, when the user is allowed to say > >>> whatever they want goes in P-A-ID? > >>> > >>> The best thing I can come up with would be to have some independent > >>> validation service that used other data sources to validate the > >>> content, and let them sign it. Then we could carry that signature > somewhere. > >>> > >>> Right now, I think we should leave it out of scope. If we can > >>> figure out a way to do validation, then we can revisit the notion of > >>> carrying evidence of validation in future work. > >>> > >>> Does argue for making sure that whatever mechanism we arrive at > >>> should have some obvious extension mechanism, perhaps along the > >>> lines of what Jon was suggesting for media properties. If you > >>> recall, he proposed to have a digest of SDP where the digest was > >>> protected by the signature, but if the SDP received didn't match the > >>> SDP sent, the termination side could know that, but the basic > >>> identity mechanism could succeed anyway (that is, you knew you had a > valid identity and a modified SDP). > >>> > >>> Brian > >>> > >>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote: > >>> > >>> Would it be possible to provide an indication of whether the calling > >>> name was validated (in the same sense that the calling number was > >>> validated, but an independent indication)?____ > >>> > >>> __ __ > >>> > >>> ISTM that should be a simple exercise, protocol-wise. And it > >>> maintains the parallel treatment of name and number that we have > >>> today (e.g., there are today separate indications of privacy, for > >>> name and number). But that's not my main concern; mostly I'm > >>> thinking of the evolution of the process by which calling name is > >>> provided. Even if it's not possible to validate calling name as > >>> provided by CNAM, it might be possible to validate calling name as > >>> provided by other methods; e.g., by the calling network in the > >>> display-name header field in the FROM or (more likely in public > >>> networks) the P-A-ID header.____ > >>> > >>> __ __ > >>> > >>> tim____ > >>> > >>> __ __ > >>> > >>> __ __ > >>> > >>> *From:*stir-bounces@ietf.org >>> 'stir-bounces@ietf.org');> [mailto:stir-bounces@ietf.org > >>> ] *On Behalf Of > >>> *PFAUTZ, PENN L > >>> *Sent:* Wednesday, August 14, 2013 9:37 AM > >>> *To:* Brian Rosen; Hadriel Kaplan > >>> *Cc:* stir@ietf.org ; > >>> Paul Kyzivat > >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > >>> Charter)____ > >>> > >>> __ __ > >>> > >>> I assume the concern in this thread is with the case where a number > >>> might be authenticated but the CNAM displayed would be misleading > >>> because of lax policies of the CNAM provider - e.g., the bad guy > >>> makes a call from what is indeed his legit number but has managed to > >>> get Bank of America into his CNAM entry.____ > >>> > >>> __ __ > >>> > >>> I'm thinking that taking on CNAM in the ietf may be a bridge too far > >>> for stir. Leave what happens after the number is validated up to > >>> national authorities since arrangements may differ. And at least in > >>> the case above it should be possible to trace back to the > >>> perp.____ > >>> > >>> __ __ > >>> > >>> More generally I think the object of stir ought to be just to > >>> provide the customer an indication of whether the calling number was > >>> validated on not - whether calls get blocked or unvalidated numbers > >>> are still displayed should be up to the customer and their service > >>> provider.____ > >>> > >>> __ __ > >>> > >>> Penn Pfautz____ > >>> > >>> AT&T Access Management____ > >>> > >>> +1-732-420-4962____ > >>> > >>> *From:*stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On > >>> Behalf Of *Brian Rosen > >>> *Sent:* Wednesday, August 14, 2013 9:32 AM > >>> *To:* Hadriel Kaplan > >>> *Cc:* stir@ietf.org; Paul Kyzivat > >>> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to > >>> Charter)____ > >>> > >>> __ __ > >>> > >>> I think we probably should keep CNAM out of this for now > >>> anyway.____ > >>> > >>> __ __ > >>> > >>> The advantage of the credential delegation process as we have > >>> defined it is that it's authoritative.____ > >>> > >>> __ __ > >>> > >>> The current CNAM databases cannot be called "authoritative" really. > >>> Classically, as you describe, there is a database operated by on > >>> on behalf of the origination carrier and queried by the termination > >>> carrier (often with a charge to query). The content is what the > >>> carrier has recorde from the original service order, but there isn't > >>> any attempt to validate those names, and there are carriers who will > >>> let you put anything you like in there. How "authoritative" is > >>> that? Then there are other databases, like Neustar's, that don't > >>> have any relationship to the originination carrier - the termination > >>> carrier dips an independently developed database of name-number > >>> relationships. These databases are developed using a wide variety > >>> of sources and have evolved to be very accurate, but hardly > >>> "authoritative".____ > >>> > >>> __ __ > >>> > >>> And yes, Hadriel, there are regulatory restrictions, mostly about > >>> what the NPAC (number portability database administrator) can do. > >>> The CNAM databases have very few regulations to deal with.____ > >>> > >>> __ __ > >>> > >>> Brian ____ > >>> > >>> > >>> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ > >>> > >>> > >>> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat >>> > >> > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7b5db1b047bc1d04e450a64e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are accurate databases for human names in most devel= oped countries. =A0Further, the databases you refer to would not have the i= nformation needed to associate a business name with all of the numbers that= the business might use. =A0There are databases that have much of the infor= mation, but would likely need some enhancement to have ALL of the possible = numbers.

The issue I think we need to deal with has two aspects:
1. The entity asserting the name can't really claim authority bec= ause there is no delegation chain for "John Smith" =A0or "Wo= rld Wide Widgets". =A0There are third parties that can assert some lev= el of assurance that the name goes with the number.

2. The assurance you get is not binary. =A0There is a s= core.

So, I think the way this would work is that = a third party asserts a likelihood score that the name asserted in the sign= aling is valid. =A0This would work the best if the originating service prov= ider asserted the score. =A0The reason why is that the score is better the = more information is known. =A0If the originating SP provides the assurance = service information like service address, or other identifying information,= the confidence is better, and the score can be higher. =A0If there are onl= y a few assurance services, their credentials could be known by the termina= ting end, and some form of the score signed by the service could be attache= d to the call and verified at the termination. =A0The terminating end could= use an assurance service of its own choosing, but it would likely have onl= y the name and number as input, and thus have a limited score range to work= with.

I do think that if there was a notion of a category (ba= nk, insurance company, doctor) included in the data, possibly with its own = score, that would help.

I think this is outside th= e charter. =A0We can either decide to work on this later here in stir, or s= tart a parallel effort.

Brian



On Mon, Aug 19, 2013 at 1:25 PM, Hen= ning Schulzrinne <Henning.Schulzrinne@fcc.gov> wro= te:
I see no reason not to have either the servi= ce provider or a third party provide this information. In some cases, impor= tant information (e.g., the holding of licenses or business permits) is onl= y readily available via third parties. I don't think the local phone co= mpany wants to validate whether the lawyer is admitted to the bar, the doct= or, charity or driveway sealer are state-licensed and the bank is FDIC-insu= red, but all of these are at least as important as the plain name to reduce= fraud. Such additional indications make look-alike impersonation much less= likely, i.e., where the perp uses "Bank for America" or typos to= fool the quick glance.

However, generally, trusted entities tend to be somewhat larger and few. It= is unlikely that a diligent rural ILEC or CLEC will ever accrue enough rec= ognition to be on the "known diligent" list. You then either end = up with a browser-like mechanism of endowing certain gatekeepers with a sea= l of approval, or you can at least separate the two functions, where needed= . The small rural ILEC may decide that it's better to let the Chamber o= f Commerce or the state corporation board do this. Verizon and kin, on the = other hand, may well want to acquire a reputation of validating their custo= mer identities.

Thus, my suggestion to allow for both originating service provider and thir= d-party models.

-----Original Message-----
From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] O= n Behalf Of Dwight, Timothy M (Tim)
Sent: Friday, August 16, 2013 9:30 AM
To: Hadriel Kaplan
Cc: stir@ietf.org List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

The ability to "cross-check" or otherwise validate the contents o= f a database, is not unique to "3rd parties". =A0It baffles me wh= y involving a 3rd party would be expected to make things better. =A0AFAICS = the service provider and the 3rd party are equally capable of being vigilen= t with respect to the content of their database; but the service provider i= s uniquely positioned by virtue of his ongoing business relationship with t= he calling party. =A0That relationship gives him greater access to informat= ion about the customer's identity, and more incentive to manage it prop= erly, than a 3rd party would have.

That doesn't eliminate the potential for "dodgy" service prov= iders. =A0Obviously. =A0But 3rd party database providers have the same pote= ntial to be "dodgy", and less incentive not to be.

I wish that last comment were true, but I don't think it is. =A0The pro= blem is that "dodgy" entities typically interconnect to the PSTN = via wholesale services provided by a "traditional" carrier. =A0To= exchange traffic with them you go through their wholesale provider. =A0Eve= n if A and B directly interconnect, and neither is the least bit "dodg= y", there may be sitting behind one or both of them, carriers that are= . =A0Even if A and B trust one another completely I think they would still = want to be protected from one anothers' wholesale customers. =A0And bes= ides, in business nobody ever trusts anybody completely :-).

tim


-----Original Message-----
From: Hadriel Kaplan [mailto:h= adriel.kaplan@oracle.com]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: stir@ietf.org List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)


So what that says to me is you can't trust a CA - or at least not all t= he "CAs". =A0I've been told that some CNAM DB providers don&#= 39;t just blindly believe LIDB entries, but actually perform cross-referenc= e checking with other data. (if they even populated the data from LIDB to b= egin with)

But that's one of the reasons it feels logical to me to keep it in a se= parate 3rd-party database, because you can't just trust what comes in o= n SIP/SS7 - you need a third party to perform some verification/cross-check= ing of the data, and in-advance as opposed to just when the call comes in.<= br>
(BTW, this is not the case for direct VoIP interconnection of call originat= or and terminator - for that you don't need STIR nor 3rd party CNAM dat= abases)

-hadriel


On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" <timothy.dwight@verizon.com> = wrote:

> The problem is the CNAM lookup isn't trustworthy. =A0"dodgy&q= uot; carriers can and do run their own LIDBs. =A0As do all sorts of 3rd par= ties, who get information from God-only-knows where, about individuals with= whom they have no business relationship (so, no incentive to "keep ha= ppy").
>
> Providing a validated calling number would not protect my mom from a s= cammer who's got a number from such a "dodgy" carrier, and ha= s been allowed by that carrier to associate with it the name of her bank. = =A0AFAICT it only helps entities that operate their own identity database, = e.g., LEAs and PSAPs.
>
> tim
>
>
> -----Original Message-----
> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]
> Sent: Thursday, August 15, 2013 9:16 PM
> To: Dwight, Timothy M (Tim)
> Cc: stir@ietf.org List
> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to
> Charter)
>
>
> I may be misunderstanding you, but I think we're kind of getting a= solution to that... though maybe not in a way that people want.
>
> For sake of argument, let's ignore the technology or any proposed = solution for STIR, or even STIR in general. =A0Also ignore the existing CNA= M business model and pretend we wanted to provide CNAM for the first time, = from scratch.
>
> We know we can't just trust callerid4u to claim any CNAM it wanted= to. =A0So let's say instead of trusting callerid4u, we designated some= common CA to verify and sign CNAM information for everyone, and everyone h= as to trust them. =A0This CA used various sources of information and verifi= cation to create a "certificate" that said "for this phone n= umber X, the user's name is Jane Doe", or maybe "for the hold= er of the private key for this public key, the user's name is Jane Doe&= quot; (which is basically what web certificates say).
>
> So then we look at how to put this into SIP, and instead of putting th= e whole certificate in the INVITE, we use an external database lookup mecha= nism. =A0That's basically STIR, for the phone number part. =A0And the e= xisting CNAM databases are basically the "CA", where they provide= a trusted lookup database of phone-number -> CNAM. =A0Since STIR valida= tes the phone number, the CNAM database lookup should be valid... assuming = you trust the CNAM database to be valid to begin with. =A0But if you *don&#= 39;t* trust it, it's not clear why you'd trust any other CA either.=
>
> So we already have (or will once we have STIR) a way to get a fairly v= alid CNAM, if you believe in a CA model for that. =A0What we don't have= is a different pricing/business model for how the "CA" charges f= or retrieving the "certificate" data. =A0But I don't think it= 's the technology that causes this really, so it's not something we= can fix here. =A0I mean even web CAs charge an impressive amount of money = for web certificates, and the technology part of the job is trivial for the= m, afaik. =A0They charge what they believe the market will bear.
>
> -hadriel
>
>
> On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" <<= a href=3D"mailto:timothy.dwight@verizon.com">timothy.dwight@verizon.com= > wrote:
>
>> With respect, I think statements like " I don't see how s= igning helps " put the cart before the horse. =A0Signing is an attribu= te of a possible solution, not a requirement.
>>
>> It is precisely the www.callerid4u.com scenario you note, that worries me. =A0I= STM that if we declare any sort of validation for calling name to be out of= scope, we provide no solution to the victims of scams enabled by services = that allow dishonest actors to associate the name of a bank with their phon= e number.
>>
>> I recognize that names are not delegated in the same way that numb= ers are, and that there are all sorts of semantic nuances that make their v= alidation difficult. =A0Still, CA's do it. =A0And it's been propose= d on this list that a smartphone app could do it. =A0So I don't see why= we're so quick to agree we can't do it. =A0Or at least, do somethi= ng.
>>
>> I'm a pragmatist. =A0Maybe we can't do as good a job valid= ating names as we can numbers. =A0I still think it's better to make thi= ngs better than to do nothing. =A0For example ISTM it'd be positive pro= gress to enable the called party to make a more informed decision about whe= ther to trust the calling name, than he can today.
>>
>> tim
>>
>> p.s. I tend to agree with Rich, that we can't forever duck the= issue of what gets presented to the called party. =A0Whether it's addr= essed directly or not, we're already making assumptions about what is a= nd isn't reasonable.
>>
>>
>> -----Original Message-----
>> From: stir-bounces@ietf.o= rg [mailto:stir-bounces@ietf.o= rg] On Behalf
>> Of Henning Schulzrinne
>> Sent: Wednesday, August 14, 2013 2:19 PM
>> To: 'Paul Kyzivat'; Brian Rosen
>> Cc: stir@ietf.org
>> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to
>> Charter)
>>
>> Just piling on... There are at least three levels of information h= ere, making it difficult to do that within the signaling framework:
>>
>> * the name of the person calling (vs. the subscriber name)
>> * the name of the organization
>> * properties of the organization ("licensed plumber", &q= uot;FDIC-insured
>> bank", "located in Washington, DC", "registere= d charity")
>>
>> This is more whois-like information than just the SIP display name= . In the certificate space, we have two levels: (1) assertion of domain nam= e control; (2) EV (extended validation) certs. It would be interesting to s= ee how well the EV concept has worked out in practice.
>>
>> I don't see how signing helps here at all, for the reasons men= tioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a leg= itimate number with just about any name string. And for corporate accounts,= the service provider has no way of knowing whether Tom Sawyer is really at= a particular number in a range and whether that entity prefers to list the= name of the person, just the organization, the location ("PizzaHut Le= onia") or something else. Indeed, the same number can legitimately hav= e multiple display names that change quickly over time (e.g., staff at the = doctor's office).
>>
>> Verifiable whois-like information could be very useful and service= providers could see that as an opportunity, given that they do know a lot = about their customers, such as their billing and service address and how lo= ng they have been in business. But it's a separate problem, probably mo= re closely related to the number allocation problem.
>>
>> -----Original Message-----
>> From: stir-bounces@ietf.o= rg [mailto:stir-bounces@ietf.o= rg] On Behalf
>> Of Paul Kyzivat
>> Sent: Wednesday, August 14, 2013 3:04 PM
>> To: Brian Rosen
>> Cc: stir@ietf.org; Hadriel Ka= plan; Dwight, Timothy M (Tim); PFAUTZ,
>> PENN L
>> Subject: Re: [stir] Early Homework (was Re: Moving from BOF to
>> Charter)
>>
>> On 8/14/13 8:38 PM, Brian Rosen wrote:
>>> I suppose it's possible, but what is the criteria for vali= dation?
>>>
>>> With TNs, we have credentials that accompany number delegation= - we
>>> have a clear path to assuring that the caller asserting the id= entity
>>> is indeed entitled to claim control of that number (well, SPs<= br> >>> mostly, not the caller, at least initially). =A0There is no eq= uivalent
>>> assurance for CNAM.
>>>
>>> I don't want to get into a fight over which database is be= tter, but
>>> the alternate, doesn't depend on the origination carrier m= echansism
>>> is statisically actually a better "validation" of th= e content than
>>> what a traditional carrier gets in his service order (because = they
>>> usually don't actually validate the content), and is infin= iately
>>> better than the carriers that allow the consumer to put anythi= ng
>>> they want in the database. =A0Without a reasonable way to assu= re that
>>> the database is actually valid, what is the value of carrying = an assertion?
>>
>> While I recognize that letting the customer put in whatever they w= ant
>> is problematic, I have no idea whether the alternative of letting = the
>> CNAM provider include whatever they want is "better". (H= ow would we
>> measure
>> that?)
>>
>> (I've just been trying to deal with an "information aggre= gator" that
>> is publishing wrong information about me and won't change it. = So I'm
>> not feeling good about that sort of thing.)
>>
>> ISTM that is is yet another example of ancient, informal, manual >> systems, that once mostly "worked" based on the good wil= l of the
>> people involved, but that have now been automated into monstrositi= es
>> that nobody understands. (Management of healthcare data is another=
>> example.)
>>
>> Ultimately there will need to be a big effort to develop a formal = framework for this. And it will probably require the creation of new laws.<= br> >>
>> Alternatively this could be left to the open market. (E.g., The >> callee could just Google the calling number.)
>>
>> In any case STIR can't go down this rat hole.
>>
>> =A0 =A0 =A0Thanks,
>> =A0 =A0 =A0Paul
>>
>>> If we had such a mechanism, what prevents one of the carriers = that
>>> let's you put anything you want in the database from asser= ting that
>>> the content of P-A-ID is valid, when the user is allowed to sa= y
>>> whatever they want goes in P-A-ID?
>>>
>>> The best thing I can come up with would be to have some indepe= ndent
>>> validation service that used other data sources to validate th= e
>>> content, and let them sign it. =A0Then we could carry that sig= nature somewhere.
>>>
>>> Right now, I think we should leave it out of scope. =A0If we c= an
>>> figure out a way to do validation, then we can revisit the not= ion of
>>> carrying evidence of validation in future work.
>>>
>>> Does argue for making sure that whatever mechanism we arrive a= t
>>> should have some obvious extension mechanism, perhaps along th= e
>>> lines of what Jon was suggesting for media properties. =A0If y= ou
>>> recall, he proposed to have a digest of SDP where the digest w= as
>>> protected by the signature, but if the SDP received didn't= match the
>>> SDP sent, the termination side could know that, but the basic<= br> >>> identity mechanism could succeed anyway (that is, you knew you= had a valid identity and a modified SDP).
>>>
>>> Brian
>>>
>>> On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote:<= br> >>>
>>> =A0 Would it be possible to provide an indication of whether t= he calling
>>> =A0 name was validated (in the same sense that the calling num= ber was
>>> =A0 validated, but an independent indication)?____
>>>
>>> =A0 __ __
>>>
>>> =A0 ISTM that should be a simple exercise, protocol-wise. =A0A= nd it
>>> =A0 maintains the parallel treatment of name and number that w= e have
>>> =A0 today (e.g., there are today separate indications of priva= cy, for
>>> =A0 name and number). =A0But that's not my main concern; m= ostly I'm
>>> =A0 thinking of the evolution of the process by which calling = name is
>>> =A0 provided. =A0Even if it's not possible to validate cal= ling name as
>>> =A0 provided by CNAM, it might be possible to validate calling= name as
>>> =A0 provided by other methods; e.g., by the calling network in= the
>>> =A0 display-name header field in the FROM or (more likely in p= ublic
>>> =A0 networks) the P-A-ID header.____
>>>
>>> =A0 __ __
>>>
>>> =A0 tim____
>>>
>>> =A0 __ __
>>>
>>> =A0 __ __
>>>
>>> =A0 *From:*stir-bounc= es@ietf.org <javascript:_e({}, 'cvml',
>>> =A0 'stir-bounces= @ietf.org');> [mailto:s= tir-bounces@ietf.org
>>> =A0 <javascript:_e({}, 'cvml', 'stir-bounces@ietf.org');>] *On Behalf = Of
>>> =A0 *PFAUTZ, PENN L
>>> =A0 *Sent:* Wednesday, August 14, 2013 9:37 AM
>>> =A0 *To:* Brian Rosen; Hadriel Kaplan
>>> =A0 *Cc:* stir@ietf.org &= lt;javascript:_e({}, 'cvml', '= stir@ietf.org');>;
>>> =A0 Paul Kyzivat
>>> =A0 *Subject:* Re: [stir] Early Homework (was Re: Moving from = BOF to
>>> =A0 Charter)____
>>>
>>> =A0 __ __
>>>
>>> =A0 I assume the concern in this thread is with the case where= a number
>>> =A0 might be authenticated but the CNAM displayed would be mis= leading
>>> =A0 because of lax policies of the CNAM provider - e.g., the b= ad guy
>>> =A0 makes a call from what is indeed his legit number but has = managed to
>>> =A0 get Bank of America into his CNAM entry.____
>>>
>>> =A0 __ __
>>>
>>> =A0 I'm thinking that taking on CNAM in the ietf may be a = bridge too far
>>> =A0 for stir. Leave what happens after the number is validated= up to
>>> =A0 national authorities since arrangements may differ. And at= least in
>>> =A0 the case above it should be possible to trace back to the<= br> >>> perp.____
>>>
>>> =A0 __ __
>>>
>>> =A0 More generally I think the object of stir ought to be just= to
>>> =A0 provide the customer an indication of whether the calling = number was
>>> =A0 validated on not - whether calls get blocked or unvalidate= d numbers
>>> =A0 are still displayed should be up to the customer and their= service
>>> =A0 provider.____
>>>
>>> =A0 __ __
>>>
>>> =A0 Penn Pfautz____
>>>
>>> =A0 AT&T Access Management____
>>>
>>> =A0 += 1-732-420-4962____
>>>
>>> =A0 *From:*stir-bounc= es@ietf.org [mailto:stir-bounc= es@ietf.org] *On
>>> =A0 Behalf Of *Brian Rosen
>>> =A0 *Sent:* Wednesday, August 14, 2013 9:32 AM
>>> =A0 *To:* Hadriel Kaplan
>>> =A0 *Cc:* stir@ietf.org; = Paul Kyzivat
>>> =A0 *Subject:* Re: [stir] Early Homework (was Re: Moving from = BOF to
>>> =A0 Charter)____
>>>
>>> =A0 __ __
>>>
>>> =A0 I think we probably should keep CNAM out of this for now >>> anyway.____
>>>
>>> =A0 __ __
>>>
>>> =A0 The advantage of the credential delegation process as we h= ave
>>> =A0 defined it is that it's authoritative.____
>>>
>>> =A0 __ __
>>>
>>> =A0 The current CNAM databases cannot be called "authorit= ative" really.
>>> =A0 =A0 Classically, as you describe, there is a database oper= ated by on
>>> =A0 on behalf of the origination carrier and queried by the te= rmination
>>> =A0 carrier (often with a charge to query). =A0The content is = what the
>>> =A0 carrier has recorde from the original service order, but t= here isn't
>>> =A0 any attempt to validate those names, and there are carrier= s who will
>>> =A0 let you put anything you like in there. =A0How "autho= ritative" is
>>> =A0 that? =A0Then there are other databases, like Neustar'= s, that don't
>>> =A0 have any relationship to the originination carrier - the t= ermination
>>> =A0 carrier dips an independently developed database of name-n= umber
>>> =A0 relationships. =A0These databases are developed using a wi= de variety
>>> =A0 of sources and have evolved to be very accurate, but hardl= y
>>> =A0 "authoritative".____
>>>
>>> =A0 __ __
>>>
>>> =A0 And yes, Hadriel, there are regulatory restrictions, mostl= y about
>>> =A0 what the NPAC (number portability database administrator) = can do.
>>> =A0 The CNAM databases have very few regulations to deal with.= ____
>>>
>>> =A0 __ __
>>>
>>> =A0 Brian ____
>>>
>>>
>>> =A0 On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____ >>>
>>>
>>> =A0 On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <pk
>>>
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir
_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--047d7b5db1b047bc1d04e450a64e-- From kent@bbn.com Mon Aug 19 10:57:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B0621F94FF for ; Mon, 19 Aug 2013 10:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo-XI5WUVESC for ; Mon, 19 Aug 2013 10:57:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA0711E8146 for ; Mon, 19 Aug 2013 10:57:06 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:42181 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBThQ-000Og5-Kh; Mon, 19 Aug 2013 13:57:04 -0400 Message-ID: <52125C6E.7030809@bbn.com> Date: Mon, 19 Aug 2013 13:57:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hadriel.kaplan@oracle.com" , 'Michael Hammer' , "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:57:15 -0000 Henning, > That's why I mentioned third parties, such as (without any implied endorsement, obviously) D&B. The goal is to allow one or more such third parties, but allow the business to tie their E.164 keypair to that registration. That seems relatively simple - if the whois-style information contains a signature block with the same private key that's used for the number, the recipient can easily check that they are connected, without the name database being tied in any organizational way to the E.164 database. > D&B was explored as a candidate CA for organizations long ago, in the PKI world. It didn't work out. In Italy, the chambers of commerce were considered appropriate candidates as CAs for businesses, for electronic financial transactions. Not sure if that has progressed. We have several decades of experience in trying to do this, in the PKI space, with the EU having pushed harder than anywhere else. I agree with your bottom line observation, i.e., assume independence from the E.164 database. (I would add, don't expect a great outcome!). Steve From Henning.Schulzrinne@fcc.gov Mon Aug 19 11:06:16 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3047E21F880F for ; Mon, 19 Aug 2013 11:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_BIZOP=0.7] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXJYkYkrcIWo for ; Mon, 19 Aug 2013 11:06:11 -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 A371C21F8C4C for ; Mon, 19 Aug 2013 11:06:10 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbCAAZhJ4IAAtYSAgAAwhgCAAGoAgIAAIfKAgASzCVCAAE4lAP//vXbA Date: Mon, 19 Aug 2013 18:05:39 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@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: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FBBEC40p2pxmb13fccnetw_" MIME-Version: 1.0 Cc: "stir@ietf.org List" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:06:16 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FBBEC40p2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As you say, there are currently no databases that associate numbers with co= rporate records, but such association doesn't seem all that hard, assuming = that the owners of those databases see a business opportunity. They are, li= ke Steve says, authoritative for the business name. They also have known co= ntact points at those corporations, so impersonation is a lot harder. The model would be that the existing business record (e.g., credit reportin= g or state agencies) allow their registered entities to add numbers to the = record. They wouldn't need to add all their numbers - the numbers used for = outbound calls to customers would be sufficient, not every desk phone of ba= ckoffice staff with no customer contact. For large entities such as most ba= nks, they could also simply provide a public key in the record, indicating = that every number signed with the corresponding private key is theirs. The receiving entity queries the database with the name, number or public k= ey. Yes, it's largely a separate effort, but we do want to most likely tie the = crypto credentials, so discussing how they might work together seems helpfu= l. From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 19, 2013 1:56 PM To: Henning Schulzrinne Cc: Dwight, Timothy M (Tim); Hadriel Kaplan; stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) There are accurate databases for human names in most developed countries. = Further, the databases you refer to would not have the information needed t= o associate a business name with all of the numbers that the business might= use. There are databases that have much of the information, but would lik= ely need some enhancement to have ALL of the possible numbers. The issue I think we need to deal with has two aspects: 1. The entity asserting the name can't really claim authority because there= is no delegation chain for "John Smith" or "World Wide Widgets". There a= re third parties that can assert some level of assurance that the name goes= with the number. 2. The assurance you get is not binary. There is a score. So, I think the way this would work is that a third party asserts a likelih= ood score that the name asserted in the signaling is valid. This would wor= k the best if the originating service provider asserted the score. The rea= son why is that the score is better the more information is known. If the = originating SP provides the assurance service information like service addr= ess, or other identifying information, the confidence is better, and the sc= ore can be higher. If there are only a few assurance services, their crede= ntials could be known by the terminating end, and some form of the score si= gned by the service could be attached to the call and verified at the termi= nation. The terminating end could use an assurance service of its own choo= sing, but it would likely have only the name and number as input, and thus = have a limited score range to work with. I do think that if there was a notion of a category (bank, insurance compan= y, doctor) included in the data, possibly with its own score, that would he= lp. I think this is outside the charter. We can either decide to work on this = later here in stir, or start a parallel effort. Brian --_000_E6A16181E5FD2F46B962315BB05962D01FBBEC40p2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As you say, there are cur= rently no databases that associate numbers with corporate records, but such= association doesn’t seem all that hard, assuming that the owners of those databases see a business opportunity. They are, like Steve= says, authoritative for the business name. They also have known contact po= ints at those corporations, so impersonation is a lot harder.

 <= /p>

The model would be that t= he existing business record (e.g., credit reporting or state agencies) allo= w their registered entities to add numbers to the record. They wouldn’t need to add all their numbers – the numbers used= for outbound calls to customers would be sufficient, not every desk phone = of backoffice staff with no customer contact. For large entities such as mo= st banks, they could also simply provide a public key in the record, indicating that every number signed with the correspond= ing private key is theirs.

 <= /p>

The receiving entity quer= ies the database with the name, number or public key.

 <= /p>

Yes, it’s largely a= separate effort, but we do want to most likely tie the crypto credentials,= so discussing how they might work together seems helpful.

 <= /p>

From: Brian Ro= sen [mailto:br@brianrosen.net]
Sent: Monday, August 19, 2013 1:56 PM
To: Henning Schulzrinne
Cc: Dwight, Timothy M (Tim); Hadriel Kaplan; stir@ietf.org List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Chart= er)

 

There are accurate databases for human names in most= developed countries.  Further, the databases you refer to would not h= ave the information needed to associate a business name with all of the num= bers that the business might use.  There are databases that have much of the information, but would likely need som= e enhancement to have ALL of the possible numbers.

 

The issue I think we need to deal with has two aspec= ts:

1. The entity asserting the name can't really claim = authority because there is no delegation chain for "John Smith" &= nbsp;or "World Wide Widgets".  There are third parties that = can assert some level of assurance that the name goes with the number.=

 

2. The assurance you get is not binary.  There = is a score.

 

So, I think the way this would work is that a third = party asserts a likelihood score that the name asserted in the signaling is= valid.  This would work the best if the originating service provider = asserted the score.  The reason why is that the score is better the more information is known.  If the origi= nating SP provides the assurance service information like service address, = or other identifying information, the confidence is better, and the score c= an be higher.  If there are only a few assurance services, their credentials could be known by the terminating en= d, and some form of the score signed by the service could be attached to th= e call and verified at the termination.  The terminating end could use= an assurance service of its own choosing, but it would likely have only the name and number as input, and thus have = a limited score range to work with.

 

I do think that if there was a notion of a category = (bank, insurance company, doctor) included in the data, possibly with its o= wn score, that would help.

 

I think this is outside the charter.  We can ei= ther decide to work on this later here in stir, or start a parallel effort.=

 

Brian

 

 

--_000_E6A16181E5FD2F46B962315BB05962D01FBBEC40p2pxmb13fccnetw_-- From kent@bbn.com Mon Aug 19 11:17:38 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB83111E8146 for ; Mon, 19 Aug 2013 11:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RNegTzIZdH6 for ; Mon, 19 Aug 2013 11:17:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA7011E8145 for ; Mon, 19 Aug 2013 11:17:31 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37384 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBU1B-000P6U-DT; Mon, 19 Aug 2013 14:17:29 -0400 Message-ID: <52126137.7090503@bbn.com> Date: Mon, 19 Aug 2013 14:17:27 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , "hadriel.kaplan@oracle.com" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:17:38 -0000 Henning, > ... > > Thus, to get to the solution space, I can see three directions that might be productive: > > (1) Provide an indication by a trusted party (such as the terminating provider) as to the provenance of the textual callerID information. This will then allow other tools to provide, for example, some visual indication of the trustworthiness, without the provider having to make that editorial judgment. we have provided an ability to include a logo for a CA in X.509 certs for many years. It is (almost?) never used. > (2) Provide a whois-like mechanism for more extensive information at least equivalent to EV certs, possibly signed by the same key used for numbers, to prevent the CA issues. This would only be available to smartphones (but also case (1)) and is primarily meant to identify commercial identities. I see this as a separate effort; expect to hear more about this shortly. It needs to be cryptographically-coupled with the E.164 mechanism, even if provided by another party such as D&B. based on many years of experience in the generic PKI arena, paid third parties acting as trust providers are problematic. And, EV certs are not a great solution, unless you happen to be a CA getting paid to issue them :-). > (3) For the SIP display-name case with end-to-end delivery, it would be helpful to have a way to sign both name and number. This doesn't deal with impostors or look-alike names, but other attacks outlined earlier. yes, one could bind the two together, perhaps by binding signed assertions about each under a common signature. but I worry about the many, opportunities for this to go south. > As number assignment goes beyond the realm of "few big companies with regulator visitors to the regulators" (in the FCC context, the "blue badge people"), we will face the same or similar whois-type issues that ICANN is dealing with. Fortunately, we have somewhat more local enforcement mechanisms, so the problem may be more tractable. maybe. > As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chances that callees will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information. > I agree. But, I worry about the contra-positive case too, i.e., any form of signed assertion may be interpreted as secure, with predictable, adverse consequences. Let's be modest in our goals for this WG, at least initially. Steve From kent@bbn.com Mon Aug 19 11:24:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881BE11E814F for ; Mon, 19 Aug 2013 11:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiMZAnpCvpQV for ; Mon, 19 Aug 2013 11:24:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A865E11E814E for ; Mon, 19 Aug 2013 11:24:43 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:42123 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBU86-000Ev1-B0; Mon, 19 Aug 2013 14:24:38 -0400 Message-ID: <521262E4.3070109@bbn.com> Date: Mon, 19 Aug 2013 14:24:36 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org List" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:24:49 -0000 Brian, > There are accurate databases for human names in most developed countries. If you Google my name you will find (at least this used to be the case) that the better known "Stephen Kent" is a professional didgeridoo player. So, knowing that a caller is "Stephen Kent" (or "Brian Rosen") is not sufficient in many contexts. My perspective is that there are no identifiers for individuals that are both globally unique and meaningful for all communication contexts. Even for organizations this is an issue, e.g., a business name or trademark is NOT protected as unique, even in a country. It is context specific, and arguing about the context makes attorneys wealthy! We do agree on one point: this topic ought to be out of scope for now. Steve From hadriel.kaplan@oracle.com Mon Aug 19 11:51:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3621F9BA4 for ; Mon, 19 Aug 2013 11:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvsHaU-pfmDZ for ; Mon, 19 Aug 2013 11:51:40 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id EA36B11E82C2 for ; Mon, 19 Aug 2013 11:51:39 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JIpcjP019621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Aug 2013 18:51:39 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JIpba9008707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 18:51:38 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JIpbti005405; Mon, 19 Aug 2013 18:51:37 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Aug 2013 11:51:36 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <555AC740-B6D3-49F1-BE7B-73AABCB1655F@oracle.com> Date: Mon, 19 Aug 2013 14:51:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555AC740-B6D3-49F1-BE7B-73AABCB1655F@oracle.com> To: Richard Barnes X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org List" Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:51:47 -0000 [I got some off-list comments on my question, so sending a clarification = to the list] To be clear, I literally don't know what that text means in terms of its = English meaning as it relates to this WG-to-be. What does it mean to "not develop any technologies based on the PSTN"?=20= Does it mean that we can't develop a technology which is also usable in = the PSTN? For example, does it mean we can't select IKES as part of the = STIR solution, because the IKES draft also describes how to perform = validation in SS7, instead of just in SIP? Does it mean if I want to = propose IKES, I need to pull out the SS7-related content? I asked what the rationale was because usually what happens is an IESG = member raises some concern about something, and addressing the concern = results in such text getting added to a charter with the intention of = preventing something bad from happening in the WG... but the IESG review = page for the STIR charter doesn't show anything about that for this = case. -hadriel On Aug 19, 2013, at 12:05 PM, Hadriel Kaplan = wrote: >=20 > I don't know what this means: > It is important to note that while the main focus of this = working group=09 > is telephone numbers, the STIR working group will not develop = any=09 > technologies based on the PSTN. >=20 > What was the rationale behind adding that, and what was the intent? >=20 > -hadriel >=20 >=20 > On Aug 19, 2013, at 10:53 AM, Richard Barnes wrote: >=20 >> Dear STIR, >>=20 >> In response to some comments from the IESG, we've made a few changes = to the STIR charter. The new proposed text has been uploaded to the = datatracker: >> >> Diff here: >> = >>=20 >> Please reply to this message by Wednesday, 21 Aug if you have any = issues with these changes. >>=20 >> Thanks, >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Mon Aug 19 11:53:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A8521F9C86 for ; Mon, 19 Aug 2013 11:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.595 X-Spam-Level: X-Spam-Status: No, score=-101.595 tagged_above=-999 required=5 tests=[AWL=1.381, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FklDk6fDDRWx for ; Mon, 19 Aug 2013 11:53:35 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A26811E82C2 for ; Mon, 19 Aug 2013 11:53:31 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so4937115pad.18 for ; Mon, 19 Aug 2013 11:53:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IQdqlfzsYddTeqyY9xepcQOVECEpskhVxv+ryT7wEGE=; b=kDDZRJlnLwxm4Fibg+p9UTMFmlnt5qXp2tOfVxxHUyHyIX7qXcp5lJTo56JUSc/8Iy dVYFi/2u162HrYSzNeDldz9M9is+XSkzx9AHGFUjHTghbBsU0gRVH3M4o7epdZA2nNYU RELLsQpa5okHA/DJjAI0aucFp8DGb8zjS4gSJ8ySVsUFQQTv5PBzpOBgc2jPyOxRsYId 5JBI7rfZGcPlmvfCCWPZO+U6t2DJ1hLlJRDcTE1S8EhVIHW74yAmm45EywgdVZk0qNMW oZtDD3Hix1Hljrz3L8nr85o3NSgLUoeP0nrdG683dPmfILMcdJ0IRbZB0TGdFY7maTEX U5ZA== X-Gm-Message-State: ALoCoQmqhn7+V1qkfCfRr/dGdOYJO34jzIzOyT8tGp4Puz2Uvgwnw5nyh+Hl9PRc9WWZj2BYN7zI MIME-Version: 1.0 X-Received: by 10.66.218.98 with SMTP id pf2mr4683348pac.120.1376938409421; Mon, 19 Aug 2013 11:53:29 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Mon, 19 Aug 2013 11:53:29 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <521262E4.3070109@bbn.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> Date: Mon, 19 Aug 2013 14:53:29 -0400 Message-ID: From: Brian Rosen To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b5db1b0c586b304e451746c Cc: "stir@ietf.org List" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:53:40 -0000 --047d7b5db1b0c586b304e451746c Content-Type: text/plain; charset=ISO-8859-1 There isn't a database that will supply a unique identifier for all contexts. OTOH, if you are a US resident, we could get a pretty good score comparing your name to your phone number, and if we had an address, we probably can get a pretty high score. That would provide a pretty meaningful assurance on the name attached to a phone call if we could manage to get the mechanics worked out. These databases exist in most developed countries. This is much better than we have today, because in most cases there is no attempt to validate the name when a service provider gets a new customer. If we could use these databases to score the name associated with the number, especially if the originating service provider obtained and supplied other information to the validation service (at the initiation of service, and possibly periodically after), then the validation service could provide a pretty decent score at the termination end. On Mon, Aug 19, 2013 at 2:24 PM, Stephen Kent wrote: > Brian, > > There are accurate databases for human names in most developed countries. >> > If you Google my name you will find (at least this used to be the case) > that the better known "Stephen Kent" is a professional didgeridoo player. > So, knowing that a caller is "Stephen Kent" (or "Brian Rosen") is not > sufficient in many contexts. > > My perspective is that there are no identifiers for individuals that are > both globally unique and meaningful for all communication contexts. Even > for organizations this > is an issue, e.g., a business name or trademark is NOT protected as > unique, even in a country. It is context specific, and arguing about the > context makes attorneys wealthy! > > We do agree on one point: this topic ought to be out of scope for now. > > Steve > --047d7b5db1b0c586b304e451746c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There isn't a database that will supply a unique ident= ifier for all contexts. =A0OTOH, if you are a US resident, we could get a p= retty good score comparing your name to your phone number, and if we had an= address, we probably can get a pretty high score. =A0That would provide a = pretty meaningful assurance on the name attached to a phone call if we coul= d manage to get the mechanics worked out. =A0These databases exist in most = developed countries.

This is much better than we have today, because in most= cases there is no attempt to validate the name when a service provider get= s a new customer. =A0

If we could use these = databases to score the name associated with the number, especially if the o= riginating service provider obtained and supplied other information to the = validation service (at the initiation of service, and possibly periodically= after), then the validation service could provide a pretty decent score at= the termination end.


On Mon,= Aug 19, 2013 at 2:24 PM, Stephen Kent <kent@bbn.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Brian,

There are accurate databases for human names in most developed countries.
If you Google my name you will find (at least this used to be the case) tha= t the better known "Stephen Kent" is a professional didgeridoo pl= ayer. So, knowing that a caller is "Stephen Kent" (or "Brian= Rosen") is not sufficient in many contexts.

My perspective is that there are no identifiers for individuals that are bo= th globally unique and meaningful for all communication contexts. Even for = organizations this
is an issue, e.g., a business name or trademark is NOT protected as unique,= even in a country. It is context specific, and arguing about the context m= akes attorneys wealthy!

We do agree on one point: this topic ought to be out of scope for now.

Steve

--047d7b5db1b0c586b304e451746c-- From br@brianrosen.net Mon Aug 19 11:57:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CB211E82BD for ; Mon, 19 Aug 2013 11:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.871 X-Spam-Level: X-Spam-Status: No, score=-101.871 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xr1Ud5IcUMLd for ; Mon, 19 Aug 2013 11:57:37 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id B356611E82BA for ; Mon, 19 Aug 2013 11:57:36 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id wz12so5310436pbc.11 for ; Mon, 19 Aug 2013 11:57:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ivfPU4p09rVY+Aim+zsV7/UZ2oOkyxkkRwS2dqFyPcQ=; b=aIoR3Q9Bivtn+qbnqZHbJ56EHcayPfPMXI8oTSG4Qfm4zWy8Ht03hZy3vnW/OMxHy5 kXVEBlJOxRujM3mLFxJOGER7atcu0X9V5gag7eE546SrcfX+Y+V4tbMwFBxBkhf9AQ8q W6BBfoGb+RtnyU1VH8fnpU7yOftG537XwgnJF5/9qOjjXkXDF7/ybO00cltqEU8QTMGw nwpxtGQXFmocxqE4ASUoZ8Ua6nP+fTrUpBXsD5vmE57odi3n+0WFEjZ+c9b7edZtZnRy EBe0LQMIbqlxMmCb4P7jTfVelmblZpF/tWhzcNAn4X7PUwXhnyQGqzGtl8hmrGHiDkkd PJEg== X-Gm-Message-State: ALoCoQnhW0kaXx1F2NdPjQ0siKD7YnB+5p6v4mJpSfR/syCLa/0Ie/x7r9d/SiojXJmcG/cWnvUP MIME-Version: 1.0 X-Received: by 10.66.26.112 with SMTP id k16mr20024713pag.65.1376938654894; Mon, 19 Aug 2013 11:57:34 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Mon, 19 Aug 2013 11:57:34 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: References: <555AC740-B6D3-49F1-BE7B-73AABCB1655F@oracle.com> Date: Mon, 19 Aug 2013 14:57:34 -0400 Message-ID: From: Brian Rosen To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=bcaec52998b5671ca004e45183e6 Cc: Richard Barnes , "stir@ietf.org List" Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:57:43 -0000 --bcaec52998b5671ca004e45183e6 Content-Type: text/plain; charset=ISO-8859-1 I certainly did not read the text as prohibiting the kind of thing you proposed, but now I guess I am worried. If we need to, we could weasel word standards text like "this bag of bits can be carried in any signaling protocol that provides ..., such as SS7 UUI", but I would rather have the freedom to be more explicit. Since defining a bag of bits to be carried in UUI in no way attempts to affect SS7 signaling, I think the concerns raised would not apply to doing that. Brian On Mon, Aug 19, 2013 at 2:51 PM, Hadriel Kaplan wrote: > > [I got some off-list comments on my question, so sending a clarification > to the list] > > To be clear, I literally don't know what that text means in terms of its > English meaning as it relates to this WG-to-be. > What does it mean to "not develop any technologies based on the PSTN"? > > Does it mean that we can't develop a technology which is also usable in > the PSTN? For example, does it mean we can't select IKES as part of the > STIR solution, because the IKES draft also describes how to perform > validation in SS7, instead of just in SIP? Does it mean if I want to > propose IKES, I need to pull out the SS7-related content? > > I asked what the rationale was because usually what happens is an IESG > member raises some concern about something, and addressing the concern > results in such text getting added to a charter with the intention of > preventing something bad from happening in the WG... but the IESG review > page for the STIR charter doesn't show anything about that for this case. > > -hadriel > > > On Aug 19, 2013, at 12:05 PM, Hadriel Kaplan > wrote: > > > > > I don't know what this means: > > It is important to note that while the main focus of this working > group > > is telephone numbers, the STIR working group will not develop any > > technologies based on the PSTN. > > > > What was the rationale behind adding that, and what was the intent? > > > > -hadriel > > > > > > On Aug 19, 2013, at 10:53 AM, Richard Barnes wrote: > > > >> Dear STIR, > >> > >> In response to some comments from the IESG, we've made a few changes to > the STIR charter. The new proposed text has been uploaded to the > datatracker: > >> > >> Diff here: > >> < > http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/charter/charter-ietf-stir-00-01.txt&url2=http://www.ietf.org/charter/charter-ietf-stir-00-03.txt > > > >> > >> Please reply to this message by Wednesday, 21 Aug if you have any > issues with these changes. > >> > >> Thanks, > >> --Richard > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --bcaec52998b5671ca004e45183e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I certainly did not read the text as prohibiting the kind = of thing you proposed, but now I guess I am worried. =A0
If we need to,= we could weasel word standards text like "this bag of bits can be car= ried in any signaling protocol that provides ..., such as SS7 UUI", bu= t I would rather have the freedom to be more explicit. =A0Since defining a = bag of bits to be carried in UUI in no way attempts to affect SS7 signaling= , I think the concerns raised would not apply to doing that.

Brian



On Mon, Aug 19, 2013 at 2:51 PM, Had= riel Kaplan <hadriel.kaplan@oracle.com> wrote:

[I got some off-list comments on my question, so sending a clarification to= the list]

To be clear, I literally don't know what that text means in terms of it= s English meaning as it relates to this WG-to-be.
What does it mean to "not develop any technologies based on the PSTN&q= uot;?

Does it mean that we can't develop a technology which is also usable in= the PSTN? =A0For example, does it mean we can't select IKES as part of= the STIR solution, because the IKES draft also describes how to perform va= lidation in SS7, instead of just in SIP? =A0Does it mean if I want to propo= se IKES, I need to pull out the SS7-related content?

I asked what the rationale was because usually what happens is an IESG memb= er raises some concern about something, and addressing the concern results = in such text getting added to a charter with the intention of preventing so= mething bad from happening in the WG... but the IESG review page for the ST= IR charter doesn't show anything about that for this case.

-hadriel


On Aug 19, 2013, at 12:05 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

>
> I don't know what this means:
> =A0 =A0 =A0 It is important to note that while the main focus of this = working group
> =A0 =A0 =A0 is telephone numbers, the STIR working group will not deve= lop any
> =A0 =A0 =A0 technologies based on the PSTN.
>
> What was the rationale behind adding that, and what was the intent? >
> -hadriel
>
>
> On Aug 19, 2013, at 10:53 AM, Richard Barnes <rlb@ipv.sx> wrote:=
>
>> Dear STIR,
>>
>> In response to some comments from the IESG, we've made a few c= hanges to the STIR charter. The new proposed text has been uploaded to the = datatracker:
>> <https://datatracker.ietf.org/doc/charter-ietf-stir/= >
>> Diff here:
>> <http://www.= ietf.org/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.ietf.org/charter/charter-ie= tf-stir-00-01.txt&url2=3Dhttp://www.ietf.org/charter/charter-ietf-stir-= 00-03.txt>
>>
>> Please reply to this message by Wednesday, 21 Aug if you have any = issues with these changes.
>>
>> Thanks,
>> --Richard
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--bcaec52998b5671ca004e45183e6-- From Henning.Schulzrinne@fcc.gov Mon Aug 19 11:57:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CD211E82D6 for ; Mon, 19 Aug 2013 11:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=1.538, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLyWL8w+b2lN for ; Mon, 19 Aug 2013 11:57:53 -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 687BF11E82BA for ; Mon, 19 Aug 2013 11:57:43 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Stephen Kent' , Brian Rosen Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbCAAZhJ4IAAtYSAgAAwhgCAAGoAgIAAIfKAgASzCVCAAE4lAIAACBEA///ELRA= Date: Mon, 19 Aug 2013 18:57:11 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> In-Reply-To: <521262E4.3070109@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org List" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:57:58 -0000 I don't see uniqueness as being a major issue. The likelihood that the impo= stor will be able to register "Citibank" as a barber shop is rather low, an= d I'm not too worried about confusion between "Acme plumbing" and "Acme roo= fing", particular if the information provided contains the registered busin= ess location of the caller. Yes, I may get a call from Apple Records instea= d of the guy from the Genius Bar, but probably again not the most efficient= way to swindle callees. In other words, fraud due to confusion between two= legitimately registered names that have the same letters is possible, but = has much lower probability and is likely to raise the bar significantly. Mo= st swindlers aren't going to hire lawyers to have trademark scoping fights. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Monday, August 19, 2013 2:25 PM To: Brian Rosen Cc: Henning Schulzrinne; stir@ietf.org List; Hadriel Kaplan; Dwight, Timoth= y M (Tim) Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Brian, > There are accurate databases for human names in most developed countries. If you Google my name you will find (at least this used to be the case) tha= t the better known "Stephen Kent" is a professional didgeridoo player. So, = knowing that a caller is "Stephen Kent" (or "Brian Rosen") is not sufficien= t in many contexts. My perspective is that there are no identifiers for individuals that are bo= th globally unique and meaningful for all communication contexts. Even for = organizations this is an issue, e.g., a business name or trademark is NOT p= rotected as unique, even in a country. It is context specific, and arguing = about the context makes attorneys wealthy! We do agree on one point: this topic ought to be out of scope for now. Steve From jgunn6@csc.com Mon Aug 19 12:00:04 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970EE11E82DD; Mon, 19 Aug 2013 12:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTsvnPU18XxX; Mon, 19 Aug 2013 11:59:57 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8412711E8185; Mon, 19 Aug 2013 11:59:57 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-85.messagelabs.com!1376938793!6156122!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28792 invoked from network); 19 Aug 2013 18:59:53 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-14.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Aug 2013 18:59:53 -0000 Received: from amer-gw09.amer.csc.com (cscmail.csc.com [20.6.39.245]) by amer-mta102.csc.com (8.13.8/8.13.8) with ESMTP id r7JIu7nQ009292; Mon, 19 Aug 2013 14:56:07 -0400 In-Reply-To: <521262E4.3070109@bbn.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B954542 <521262E4.3070109@bbn.com> To: Stephen Kent MIME-Version: 1.0 X-KeepSent: 7DDD27E2:188983EB-85257BCC:0068214D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 19 Aug 2013 14:59:53 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 08/19/2013 02:53:18 PM, Serialize complete at 08/19/2013 02:53:18 PM Content-Type: multipart/alternative; boundary="=_alternative 00685C6D85257BCC_=" Cc: stir-bounces@ietf.org, Hadriel Kaplan , "stir@ietf.org List" , Brian Rosen , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:00:04 -0000 This is a multipart message in MIME format. --=_alternative 00685C6D85257BCC_= Content-Type: text/plain; charset="US-ASCII" > From: Stephen Kent > If you Google my name you will find (at least this used to be the case) > that the better known "Stephen Kent" is a professional didgeridoo > player. So, knowing that a caller is "Stephen Kent" (or "Brian Rosen") > is not sufficient in many contexts. I have it worse. If you google my name "Janet Gunn" you come up with a lot of semi-nude pictures of a grade B actress. For some reason my employer does not like me to mention this fact. Janet --=_alternative 00685C6D85257BCC_= Content-Type: text/html; charset="US-ASCII"


> From: Stephen Kent <kent@bbn.com>

> If you Google my name you will find (at least this used to be the case)
> that the better known "Stephen Kent" is a professional didgeridoo
> player. So, knowing that a caller is "Stephen Kent" (or "Brian Rosen")
> is not sufficient in many contexts.
I have it worse.

If you google my name "Janet Gunn" you come up with a lot of semi-nude pictures of a grade B actress.

For some reason my employer does not like me to mention this fact.  

Janet --=_alternative 00685C6D85257BCC_=-- From br@brianrosen.net Mon Aug 19 12:01:14 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9FE11E82FC for ; Mon, 19 Aug 2013 12:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=1.421, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uygTM5YEQg4w for ; Mon, 19 Aug 2013 12:01:07 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id B6A3F21F8B12 for ; Mon, 19 Aug 2013 12:00:50 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so5642343pdj.3 for ; Mon, 19 Aug 2013 12:00:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZQC2d0WS1VguCrTJd0P0FsVRZxbK4Nl1wTAWModx4Ew=; b=mzRksVFYFr1d7ocWn2XljjRIjaMSeF4igqkTkzMsEXgmdoN8Pz4DT5QtdsZ5s6AVBY KHDDijiT/logLry2omE4qYy12j60+MmAQ69tqNFURiiMy8M95/7DxZTChQ+KlVfqoXtG BHO69islhcf3158rnw19yxBIWQ1ZzFjVHWmeJfXtLe/uAUBJmXDZZrSxl/jC7bjDcKsl jbeN6fGB34+Ah1joT9/J6KS1CKU/vB4jZ/jOJvK7diCLUxN9HLL3luiUwibcl4X0cGUD L9c7VwBkyK/H9pALYD/KBitVXri98eIHtEVMxqwDGGNFVvBh6Kj+I3i2tG+DYibgxGaN IMDQ== X-Gm-Message-State: ALoCoQkq8u1Zdvgjd9l2pIMOeFSDNiYtxhccCgi9NDqACIc6xPCsKvBL2sZgdApH8O6z3T+qrDsz MIME-Version: 1.0 X-Received: by 10.66.240.67 with SMTP id vy3mr4379564pac.141.1376938849420; Mon, 19 Aug 2013 12:00:49 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Mon, 19 Aug 2013 12:00:49 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> Date: Mon, 19 Aug 2013 15:00:49 -0400 Message-ID: From: Brian Rosen To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=047d7b15ab7fff59ad04e4518ee6 Cc: "stir@ietf.org List" , Hadriel Kaplan , Stephen Kent , "Dwight, Timothy M \(Tim\)" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:01:14 -0000 --047d7b15ab7fff59ad04e4518ee6 Content-Type: text/plain; charset=ISO-8859-1 Yeah, I think there is a lot of merit in your category idea. It needs a taxonomy, but we probably can choose some existing one. For common use, we want one with relatively fewer categories, not trying, for example to differentiate between a life assurance agent and a property insurance agent. Brian On Mon, Aug 19, 2013 at 2:57 PM, Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> wrote: > I don't see uniqueness as being a major issue. The likelihood that the > impostor will be able to register "Citibank" as a barber shop is rather > low, and I'm not too worried about confusion between "Acme plumbing" and > "Acme roofing", particular if the information provided contains the > registered business location of the caller. Yes, I may get a call from > Apple Records instead of the guy from the Genius Bar, but probably again > not the most efficient way to swindle callees. In other words, fraud due to > confusion between two legitimately registered names that have the same > letters is possible, but has much lower probability and is likely to raise > the bar significantly. Most swindlers aren't going to hire lawyers to have > trademark scoping fights. > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, August 19, 2013 2:25 PM > To: Brian Rosen > Cc: Henning Schulzrinne; stir@ietf.org List; Hadriel Kaplan; Dwight, > Timothy M (Tim) > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) > > Brian, > > There are accurate databases for human names in most developed countries. > If you Google my name you will find (at least this used to be the case) > that the better known "Stephen Kent" is a professional didgeridoo player. > So, knowing that a caller is "Stephen Kent" (or "Brian Rosen") is not > sufficient in many contexts. > > My perspective is that there are no identifiers for individuals that are > both globally unique and meaningful for all communication contexts. Even > for organizations this is an issue, e.g., a business name or trademark is > NOT protected as unique, even in a country. It is context specific, and > arguing about the context makes attorneys wealthy! > > We do agree on one point: this topic ought to be out of scope for now. > > Steve > --047d7b15ab7fff59ad04e4518ee6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, I think there is a lot of merit in your category ide= a. =A0It needs a taxonomy, but we probably can choose some existing one. = =A0For common use, we want one with relatively fewer categories, not trying= , for example to differentiate between a life assurance agent and a propert= y insurance agent.

Brian


On Mon, Aug 19, 2013 at 2:57 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:
I don't see uniqueness as being a major = issue. The likelihood that the impostor will be able to register "Citi= bank" as a barber shop is rather low, and I'm not too worried abou= t confusion between "Acme plumbing" and "Acme roofing",= particular if the information provided contains the registered business lo= cation of the caller. Yes, I may get a call from Apple Records instead of t= he guy from the Genius Bar, but probably again not the most efficient way t= o swindle callees. In other words, fraud due to confusion between two legit= imately registered names that have the same letters is possible, but has mu= ch lower probability and is likely to raise the bar significantly. Most swi= ndlers aren't going to hire lawyers to have trademark scoping fights.

-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com= ]
Sent: Monday, August 19, 2013 2:25 PM
To: Brian Rosen
Cc: Henning Schulzrinne; stir@ietf.org List; Hadriel Kaplan; Dwight, Timothy M (Ti= m)
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Brian,
> There are accurate databases for human names in most developed countri= es.
If you Google my name you will find (at least this used to be the case) tha= t the better known "Stephen Kent" is a professional didgeridoo pl= ayer. So, knowing that a caller is "Stephen Kent" (or "Brian= Rosen") is not sufficient in many contexts.

My perspective is that there are no identifiers for individuals that are bo= th globally unique and meaningful for all communication contexts. Even for = organizations this is an issue, e.g., a business name or trademark is NOT p= rotected as unique, even in a country. It is context specific, and arguing = about the context makes attorneys wealthy!

We do agree on one point: this topic ought to be out of scope for now.

Steve

--047d7b15ab7fff59ad04e4518ee6-- From michael.hammer@yaanatech.com Mon Aug 19 12:24:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D0711E82CB for ; Mon, 19 Aug 2013 12:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDqixd0bvJrf for ; Mon, 19 Aug 2013 12:24:27 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 82FBF11E823D for ; Mon, 19 Aug 2013 12:24:27 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 19 Aug 2013 12:24:27 -0700 From: Michael Hammer To: "richard@shockey.us" , "Henning.Schulzrinne@fcc.gov" , "kent@bbn.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: Ac6c9Ozge0DbBLvpSRWm6Pzx5g4CWgAAX0KgABDioQAACirY4A== Date: Mon, 19 Aug 2013 19:24:26 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2A939@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> In-Reply-To: <012801ce9cff$491305a0$db3910e0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.107] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0107_01CE9CF0.304A41A0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:24:31 -0000 ------=_NextPart_000_0107_01CE9CF0.304A41A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Catching up on thread. The touchstone here might be: Can the phone company be held legally liable if they supply bad name data? I don't think that is the case right now. Your level of trust may vary. I'm not sure what we would be going for here. Mike -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Monday, August 19, 2013 1:12 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov; kent@bbn.com; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: RE: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Remember those databases are already in existence now. Phone companies and others have the data. A binding of number to "preferred display name" determined by the number holder as part of the service should be doable. How or if it is displayed is then the responsibility of the terminating SSP under appropriate national regulation. I agree with Henning here. "As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chances that callee will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information." It would also be nice if the UA could display something more than 15 ASCII characters, but that is a brand new issue STIR cannot, nor should it, solve. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Monday, August 19, 2013 12:14 PM To: Henning.Schulzrinne@fcc.gov; kent@bbn.com; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) There is no reason that the digital signature binding a Name to a Number could not be orthogonal and managed independently from the valid sender/Number binding. You could bundle these together, but there may be reasons to keep them separate. With names, you are now talking about a registry with personal information and you may have many folks that do not want their names made public. I could see this as being more valuable for businesses, and that may be one or two orders of magnitude fewer entities to manage. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 19, 2013 12:02 PM To: 'Stephen Kent'; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) In general, given that many users base their decision on how to treat a call on the textual caller ID, rather than the number, I think this is indeed a problem we should think about, even if the result is to punt this to another effort. As per Steve's comment, there is value of tying the provider of the name to the textual identifier, as it reduces the threat of DigiNotar-style attacks. I have a number of hypotheses: (1) Validating the names of commercial entities is more important than that of individuals. (Individuals also sometimes have legitimate reasons to provide partial information. For example, it's been a long tradition, whether justified by evidence or not, for households of single women to use initials rather than full first names in directory listings and thus also CLID.) The numbers shown to the public are likely public knowledge, so concerns about keeping them secret may be lower. (2) Legitimate businesses have an incentive to provide correct information that can be validated. The incentives of other parties are, shall we say, mixed. (3) Financial and other entities at significant risk of fraud are probably reasonably-well resourced and represented in databases such as the Dun&Bradstreet registry or government databases. (4) Whitelisting is easier than blacklisting. (5) It is helpful if name abusers can be located quickly, as that facilitates legal remedies. Thus, to get to the solution space, I can see three directions that might be productive: (1) Provide an indication by a trusted party (such as the terminating provider) as to the provenance of the textual callerID information. This will then allow other tools to provide, for example, some visual indication of the trustworthiness, without the provider having to make that editorial judgment. (2) Provide a whois-like mechanism for more extensive information at least equivalent to EV certs, possibly signed by the same key used for numbers, to prevent the CA issues. This would only be available to smartphones (but also case (1)) and is primarily meant to identify commercial identities. I see this as a separate effort; expect to hear more about this shortly. It needs to be cryptographically-coupled with the E.164 mechanism, even if provided by another party such as D&B. (3) For the SIP display-name case with end-to-end delivery, it would be helpful to have a way to sign both name and number. This doesn't deal with impostors or look-alike names, but other attacks outlined earlier. As number assignment goes beyond the realm of "few big companies with regulator visitors to the regulators" (in the FCC context, the "blue badge people"), we will face the same or similar whois-type issues that ICANN is dealing with. Fortunately, we have somewhat more local enforcement mechanisms, so the problem may be more tractable. As with number spoofing, I think an achievable goal is that unsigned, untraceable textual caller ID will be seen as dodgy and increase the chances that callees will not answer the call (or let it go to voicemail), increasing the incentive for legitimate call originators to provide identifying information. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Monday, August 19, 2013 11:28 AM To: hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Hadriel, > ... > > We know we can't just trust callerid4u to claim any CNAM it wanted to. > So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them. This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say). This aspect of your proposal already raises several concerns in my mind: - Jane Doe is not a globally unique name, so a called party can't assume that the caller is the Jane Doe that comes to mind - I strongly doubt that there is a single CA that could (should) be trusted to the identity of every caller in every country. if we have per-country CAs we start getting close to the problems we have in the browser environment. - As a rule, the best CAs are ones that are authoritative for the attributes for which they vouch. For phone numbers a lot of folks seem confident that we have the right players to perform this function. For common names, we do not (until you add a lot of context, which is often not universally meaningful), and if one tries to tie both attributes into one cert ... My bottom line is that I don't believe in the web CA model; it has failed. DANE is a much better approach, becuase it aligns name space management and public key binding. Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0107_01CE9CF0.304A41A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx OTE5MjQyNVowIwYJKoZIhvcNAQkEMRYEFE7GwdUnh+jc/6bZPE30ALjpiB+dMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAHDO5FxJB+FsZjohhJp2c6wKaCx0ouShBdDI5LFZP HDw3FDhS3qBBEuWYY35Qfxp9H/d1SypEuESPU9m7bIi973vjNEXQ6EgLtrQTR04p9M6ULS0Nc20k 1lCKL4/AU1oEoFkq+d3jt0qFIdOnAuynCghxyg+QTNMA+l/ICyzKZzcGv6JHac35HTe6R08TOVV6 w5+VWLKAdbE5Se9dbDFwlBgrfBtRT/rE1NIAoP8+OWLlgv2iwwXFu4dNrmiLyjC8RPdX8PuQwiZF MnQtMFzqUCVPbm3sUmDQ9K0uCD8whR9hW1lxOmKlMdS9m/33W1l1+Qu7MxpHk3565xd38wwOeAAA AAAAAA== ------=_NextPart_000_0107_01CE9CF0.304A41A0-- From pkyzivat@alum.mit.edu Mon Aug 19 12:38:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F013711E82BA for ; Mon, 19 Aug 2013 12:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0sxoIJLfbic for ; Mon, 19 Aug 2013 12:38:40 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 0044411E8295 for ; Mon, 19 Aug 2013 12:38:39 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id Eiwh1m0090QuhwU5Cjee21; Mon, 19 Aug 2013 19:38:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id Ejee1m00b3ZTu2S3NjeeQx; Mon, 19 Aug 2013 19:38:38 +0000 Message-ID: <5212743E.10001@alum.mit.edu> Date: Mon, 19 Aug 2013 15:38:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376941118; bh=vJaVfrull+aiQ7Ohm4R2B0fCejJoS14ILDDVVdOf/z4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pz7CeF2fGLaJn4S8nsZFg6flMrA+9hLXttCFsGlKGGwLypj00Tud7hXdSR1tM3ZEu ayWvqTWOJCKgTxTXjxqvykPgLv1SeKBkImTJQWiPfP/zoc8SnnSGsYpIQQXPF70mJJ TnRAl3LTlU456nMjbdO20oNSquliQVL21KEx+S3rUVKIRlnDInLg7T0rAzXVKJz15J GASQI/XL9pPIfLZPi/gIz4CZAe+LZkmc+KR+xKlYh9maZAdZivUZhVmQ8etjCfGlEW 1rxDHbmL0vQmSdGwMIkOxmlERR9WHXFzAjbbPtZSlhiNWbXBaiRAiVIjRiJKyvOEFQ P+7sDNsIFGEPQ== Subject: Re: [stir] XMPP X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:38:48 -0000 On 8/19/13 9:50 AM, Hadriel Kaplan wrote: >> Obviously, I failed to formulate my question. >> It was: Is IKES, any other in-band and out-of-band signalling only for SIP or for other clients also? In other words, will there be validators in non-SIP networks? (or rather, do we expect them?). > > The focus is clearly on SIP, but at least in IKES it allows SS7 and XMPP devices to be validators. The question of "do we expect them?" is a hard one, because I don't have a crystal ball. > As far as I know XMPP rarely uses E.164 numbers and rarely is involved in PSTN-style calls; so I don't expect it to do IKES anytime soon. But if XMPP usage continues to grow, it's possible that someday it might need to do it. Doesn't Google Voice use Jingle with phone numbers? Thanks, Paul From richard@shockey.us Mon Aug 19 13:22:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37C921F97C7 for ; Mon, 19 Aug 2013 13:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.539 X-Spam-Level: X-Spam-Status: No, score=-100.539 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUm8OtJ9H9kA for ; Mon, 19 Aug 2013 13:22:37 -0700 (PDT) Received: from oproxy5-pub.mail.unifiedlayer.com (oproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 25D0E21F9702 for ; Mon, 19 Aug 2013 13:22:03 -0700 (PDT) Received: (qmail 13352 invoked by uid 0); 19 Aug 2013 20:21:40 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy5.mail.unifiedlayer.com with SMTP; 19 Aug 2013 20:21:40 -0000 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:Date:Subject:To:From; bh=6jWdVoGbCJAOpOqRDnUghSFobHA7HKpAeipTRJM2hrA=; b=cQZCsSlAlZQyz40GMgDo8Jcv9dYAmsLHVWnBk4+tqA3HKICpuHTAXH8aTO1D/I7sqzkuHclC9PxLRh7ooIrnK7j3i/jjcsmSNp+of0tqcrLvHz82wnrr8yvcNber1+ns; Received: from [71.114.100.16] (port=56067 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBVxM-0004yM-42 for stir@ietf.org; Mon, 19 Aug 2013 14:21:40 -0600 From: "Richard Shockey" To: Date: Mon, 19 Aug 2013 16:21:38 -0400 Message-ID: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0193_01CE9CF8.2ECAD3F0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac6dGatLd12TFfewT0GTcH+cFoT8Mw== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Subject: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:22:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0193_01CE9CF8.2ECAD3F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf FYI . Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_000_0193_01CE9CF8.2ECAD3F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

http:= //www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf

<= p class=3DMsoNormal> 

FYI = …

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: = rshockey101
http//www.sipforum.org

"Money is the answer, what is the question?" = tm

 

 

------=_NextPart_000_0193_01CE9CF8.2ECAD3F0-- From oej@edvina.net Mon Aug 19 23:22:00 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9FA11E8101 for ; Mon, 19 Aug 2013 23:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoEnaAjofj0H for ; Mon, 19 Aug 2013 23:22:00 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E17E111E80D2 for ; Mon, 19 Aug 2013 23:21:58 -0700 (PDT) Received: from [192.168.40.30] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 5CAE493C1AF; Tue, 20 Aug 2013 06:21:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 20 Aug 2013 08:21:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Henning Schulzrinne , "stir@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: "Olle E. Johansson" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 06:22:00 -0000 19 aug 2013 kl. 18:02 skrev Henning Schulzrinne = : > In general, given that many users base their decision on how to treat = a call on the textual caller ID, rather than the number, I think this is = indeed a problem we should think about, even if the result is to punt = this to another effort. I really think we have to leave this out-of-scope for the first part of = the work. We will end up with character set issues, the need for = multiple names in different scripts and multiple persons sharing the = same phone number... I think it's just too big a problem to include if we are in a hurry to = find a solution to the primary problem - the trust of the actual caller = ID. /O= From oej@edvina.net Mon Aug 19 23:40:13 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9114811E81CD for ; Mon, 19 Aug 2013 23:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_BIZOP=0.7] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG6sXtQ0YOHu for ; Mon, 19 Aug 2013 23:40:12 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B371C11E81C9 for ; Mon, 19 Aug 2013 23:40:11 -0700 (PDT) Received: from [192.168.40.30] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id DED1F93C1AF; Tue, 20 Aug 2013 06:40:10 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_3DFF682A-2680-45E0-A377-7334123E9C36" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 20 Aug 2013 08:40:11 +0200 Message-Id: <46EB9BA5-BB66-4BE3-BA8C-5FB38632263B@edvina.net> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58 D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) Cc: "stir@ietf.org List" , "Dwight, Timothy M \(Tim\)" , "Olle E. Johansson" , Hadriel Kaplan , 'Brian Rosen' Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 06:40:13 -0000 --Apple-Mail=_3DFF682A-2680-45E0-A377-7334123E9C36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Excuse me, but I get a PKI and enum feeling when reading this. Trying to = get the TRUE caller ID name from 3rd party sources will delay this = process forever. There are tons of issues to handle here, not forgetting = privacy. Do we really need the honest-to-god true legal names or do we need to = trace who assured the name?=20 If someone fakes a name we need to be able to stop that from happening = again, we need a non-repudiation scheme so we can find who did it.=20 I see a lot of cases where a company wants to modify caller ID names for = the same number and not use the legal name. "Edvina Support" calling, = "Edvina Order dept, Elena" etc etc. I see very few cases where I need a = full legal and digital identity in the caller ID name - and if that's = needed, let's point to S/MIME (ducks). In addition, we also have a system in Sweden where the same legal = identity can have multiple company names registred...=20 /O 19 aug 2013 kl. 20:05 skrev Henning Schulzrinne = : > As you say, there are currently no databases that associate numbers = with corporate records, but such association doesn=92t seem all that = hard, assuming that the owners of those databases see a business = opportunity. They are, like Steve says, authoritative for the business = name. They also have known contact points at those corporations, so = impersonation is a lot harder. > =20 > The model would be that the existing business record (e.g., credit = reporting or state agencies) allow their registered entities to add = numbers to the record. They wouldn=92t need to add all their numbers =96 = the numbers used for outbound calls to customers would be sufficient, = not every desk phone of backoffice staff with no customer contact. For = large entities such as most banks, they could also simply provide a = public key in the record, indicating that every number signed with the = corresponding private key is theirs. > =20 > The receiving entity queries the database with the name, number or = public key. > =20 > Yes, it=92s largely a separate effort, but we do want to most likely = tie the crypto credentials, so discussing how they might work together = seems helpful. > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, August 19, 2013 1:56 PM > To: Henning Schulzrinne > Cc: Dwight, Timothy M (Tim); Hadriel Kaplan; stir@ietf.org List > Subject: Re: [stir] Early Homework (was Re: Moving from BOF to = Charter) > =20 > There are accurate databases for human names in most developed = countries. Further, the databases you refer to would not have the = information needed to associate a business name with all of the numbers = that the business might use. There are databases that have much of the = information, but would likely need some enhancement to have ALL of the = possible numbers. > =20 > The issue I think we need to deal with has two aspects: > 1. The entity asserting the name can't really claim authority because = there is no delegation chain for "John Smith" or "World Wide Widgets". = There are third parties that can assert some level of assurance that the = name goes with the number. > =20 > 2. The assurance you get is not binary. There is a score. > =20 > So, I think the way this would work is that a third party asserts a = likelihood score that the name asserted in the signaling is valid. This = would work the best if the originating service provider asserted the = score. The reason why is that the score is better the more information = is known. If the originating SP provides the assurance service = information like service address, or other identifying information, the = confidence is better, and the score can be higher. If there are only a = few assurance services, their credentials could be known by the = terminating end, and some form of the score signed by the service could = be attached to the call and verified at the termination. The = terminating end could use an assurance service of its own choosing, but = it would likely have only the name and number as input, and thus have a = limited score range to work with. > =20 > I do think that if there was a notion of a category (bank, insurance = company, doctor) included in the data, possibly with its own score, that = would help. > =20 > I think this is outside the charter. We can either decide to work on = this later here in stir, or start a parallel effort. > =20 > Brian > =20 > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_3DFF682A-2680-45E0-A377-7334123E9C36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Excuse me, but I get a PKI and = enum feeling when reading this. Trying to get the TRUE caller ID name = from 3rd party sources will delay this process forever. There are tons = of issues to handle here, not forgetting privacy.

Do = we really need the honest-to-god true legal names or do we need to trace = who assured the name? 

If someone fakes a = name we need to be able to stop that from happening again, we need a = non-repudiation scheme so we can find who did = it. 

I see a lot of cases where a company = wants to modify caller ID names for the same number and not use the = legal name. "Edvina Support" calling, "Edvina Order dept, Elena" etc = etc. I see very few cases where I need a full legal and digital = identity in the caller ID name - and if that's needed, let's point to = S/MIME (ducks).

In addition, we also have a = system in Sweden where the same legal identity can have multiple company = names = registred... 

/O


=

19 aug 2013 kl. 20:05 skrev Henning Schulzrinne = <Henning.Schulzrinne@fcc.gov>:

As you say, there are = currently no databases that associate numbers with corporate records, = but such association doesn=92t seem all that hard, assuming that the = owners of those databases see a business opportunity. They are, like = Steve says, authoritative for the business name. They also have known = contact points at those corporations, so impersonation is a lot = harder.
 
The model would be that the existing business = record (e.g., credit reporting or state agencies) allow their registered = entities to add numbers to the record. They wouldn=92t need to add all = their numbers =96 the numbers used for outbound calls to customers would = be sufficient, not every desk phone of backoffice staff with no customer = contact. For large entities such as most banks, they could also simply = provide a public key in the record, indicating that every number signed = with the corresponding private key is = theirs.
 
The receiving entity queries the database = with the name, number or public key.
 
Yes, it=92s largely a = separate effort, but we do want to most likely tie the crypto = credentials, so discussing how they might work together seems = helpful.
 
 Brian = Rosen [mailto:br@brianrosen.net] 
Sent: Monday, August 19, 2013 = 1:56 PM
To: Henning = Schulzrinne
Cc: Dwight, Timothy M (Tim); = Hadriel Kaplan; stir@ietf.org List
Subject: Re: [stir] Early Homework = (was Re: Moving from BOF to Charter)
 
There are accurate databases for human names in most developed = countries.  Further, the databases you refer to would not have the = information needed to associate a business name with all of the numbers = that the business might use.  There are databases that have much of = the information, but would likely need some enhancement to have ALL of = the possible numbers.
The = issue I think we need to deal with has two = aspects:
1. = The entity asserting the name can't really claim authority because there = is no delegation chain for "John Smith"  or "World Wide Widgets". =  There are third parties that can assert some level of assurance = that the name goes with the number.
 
2. The assurance you get is not binary.  There = is a score.
So, = I think the way this would work is that a third party asserts a = likelihood score that the name asserted in the signaling is valid. =  This would work the best if the originating service provider = asserted the score.  The reason why is that the score is better the = more information is known.  If the originating SP provides the = assurance service information like service address, or other identifying = information, the confidence is better, and the score can be higher. =  If there are only a few assurance services, their credentials = could be known by the terminating end, and some form of the score signed = by the service could be attached to the call and verified at the = termination.  The terminating end could use an assurance service of = its own choosing, but it would likely have only the name and number as = input, and thus have a limited score range to work = with.
I do = think that if there was a notion of a category (bank, insurance company, = doctor) included in the data, possibly with its own score, that would = help.
I = think this is outside the charter.  We can either decide to work on = this later here in stir, or start a parallel = effort.
In-Reply-To: <521262E4.3070109@bbn.com> Date: Tue, 20 Aug 2013 08:42:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12FB87C9-E5E0-4128-8EB2-0C2573193D03@edvina.net> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1508) Cc: Hadriel Kaplan , "Olle E. Johansson" , "stir@ietf.org List" , Brian Rosen , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 06:42:26 -0000 19 aug 2013 kl. 20:24 skrev Stephen Kent : > Brian, >> There are accurate databases for human names in most developed = countries. > If you Google my name you will find (at least this used to be the = case) that the better known "Stephen Kent" is a professional didgeridoo = player. So, knowing that a caller is "Stephen Kent" (or "Brian Rosen") = is not sufficient in many contexts. And since we have UTF-8 in the caller ID name we can propably have = different names that looks the same on the display. >=20 > My perspective is that there are no identifiers for individuals that = are both globally unique and meaningful for all communication contexts. = Even for organizations this > is an issue, e.g., a business name or trademark is NOT protected as = unique, even in a country. It is context specific, and arguing about the = context makes attorneys wealthy! >=20 > We do agree on one point: this topic ought to be out of scope for now. +1 /O= From rlb@ipv.sx Tue Aug 20 08:15:28 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2464911E8246 for ; Tue, 20 Aug 2013 08:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYqWsIeTTLSb for ; Tue, 20 Aug 2013 08:15:23 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id D9EA721F841A for ; Tue, 20 Aug 2013 08:15:19 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so1002467oag.18 for ; Tue, 20 Aug 2013 08:15:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=fP3vZDlPTyCRnULCiSAtP2yI8xEAZsj+03wV3VuLTwo=; b=DNSqK7up55BtQaJLwCFE5flfeE5oJd3KA38qgcbTu6cuFFsDsfs/9kcU8djglVQChT ZV1AMkZUZgZS/OciOEa72tnio3P6A/Hgf5YdErOhdyf2xw+MRflkjhdprFCJiLjop45z cYZJuZTlkQKDnsJyFV2R5PkitjlCcpk2rgp/jl8c3aOArCyJ7/x9YlkOLxjy5nEA0kdO qlzTm541XeQ5xXPB2ss13FEdaWrBZNstr96dtOgfiSQorQu+/M2KALmIpK6ouBD8d0nG s2XFMPjuPtkL/HqvM8tnE9mpOXbp2FIGzfYd5sei9JZVgBKUe52YsML77X8mq5jJterH pfNQ== X-Gm-Message-State: ALoCoQnYZhwbxcK5dKwbvtyMbPDW/LZTmgJSrOeUP9hwHh8Bbl6qfUJZp5ial61P3xIAkfjL27kX MIME-Version: 1.0 X-Received: by 10.182.38.228 with SMTP id j4mr1511739obk.94.1377011719306; Tue, 20 Aug 2013 08:15:19 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Tue, 20 Aug 2013 08:15:19 -0700 (PDT) X-Originating-IP: [192.1.51.54] In-Reply-To: References: Date: Tue, 20 Aug 2013 11:15:19 -0400 Message-ID: From: Richard Barnes To: "stir@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2f3a661957504e4628638 Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:15:28 -0000 --001a11c2f3a661957504e4628638 Content-Type: text/plain; charset=ISO-8859-1 New version with a few more edits: < http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/charter/charter-ietf-stir-00-03.txt&url2=http://www.ietf.org/charter/charter-ietf-stir-00-04.txt > On Mon, Aug 19, 2013 at 10:53 AM, Richard Barnes wrote: > Dear STIR, > > In response to some comments from the IESG, we've made a few changes to > the STIR charter. The new proposed text has been uploaded to the > datatracker: > > Diff here: > < > http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/charter/charter-ietf-stir-00-01.txt&url2=http://www.ietf.org/charter/charter-ietf-stir-00-03.txt > > > > Please reply to this message by Wednesday, 21 Aug if you have any issues > with these changes. > > Thanks, > --Richard > > > > > > > --001a11c2f3a661957504e4628638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon,= Aug 19, 2013 at 10:53 AM, Richard Barnes <rlb@ipv.sx> wrote:
Dear STIR,

In response to some comments= from the IESG, we've made a few changes to the STIR charter. The new p= roposed text has been uploaded to the datatracker:
Diff here:

Please reply to this message by Wednesday, 21 Aug if yo= u have any issues with these changes.

Thanks,
--Richard







--001a11c2f3a661957504e4628638-- From rlb@ipv.sx Tue Aug 20 08:18:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D43A11E8225 for ; Tue, 20 Aug 2013 08:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcBc0j4iubnH for ; Tue, 20 Aug 2013 08:17:57 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCDC11E811A for ; Tue, 20 Aug 2013 08:17:36 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n10so1007920oag.36 for ; Tue, 20 Aug 2013 08:17:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Iih1ydJfarGpQv8nhohOTgVU/r+u7V5ecWEhThdNEYA=; b=jTttUaCCdj8vp6b7T0yjcVqzNmqY4N2voNwqtgJGwAzgHBb8FwXTfgxml2zk3inMbA SBNjxKdaLCAO/smxSBq5uLKVhtrdjOB0T4C/OL2zBGnBe1XI4lpNyprzuTaKyecHVwzB +BWW88EyK9ZqJKJIeBQT52i9BsocPj5dRBGakcBG9E0kH73DDLWg4R3oui6gHKPdCOp1 1KXOHVu+W+spbZH/YYpcY6KCzgZGOSFoN57GY6hyiRfyrpGRHN1GvP1Ya7yD/+1ascgJ xouJRB8PZCCnuObfxAo0IFvfoxC8HwDB1nzuZu1JYWXeOkk06P9Fy5xyEl2CX29yCawy GSRw== X-Gm-Message-State: ALoCoQkYH0/FZADOKKV4COUEfwe5FTEdMaWdMym2krAufgcERHDR3mXj+0GjvA4Ae0xH6EBF7xn6 MIME-Version: 1.0 X-Received: by 10.182.199.74 with SMTP id ji10mr2157445obc.69.1377011855614; Tue, 20 Aug 2013 08:17:35 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Tue, 20 Aug 2013 08:17:35 -0700 (PDT) X-Originating-IP: [192.1.51.54] In-Reply-To: References: <555AC740-B6D3-49F1-BE7B-73AABCB1655F@oracle.com> Date: Tue, 20 Aug 2013 11:17:35 -0400 Message-ID: From: Richard Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=e89a8ff1c0248175cf04e4628e49 Cc: "stir@ietf.org List" Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:18:02 -0000 --e89a8ff1c0248175cf04e4628e49 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 19, 2013 at 2:51 PM, Hadriel Kaplan wrote: > > [I got some off-list comments on my question, so sending a clarification > to the list] > > To be clear, I literally don't know what that text means in terms of its > English meaning as it relates to this WG-to-be. > What does it mean to "not develop any technologies based on the PSTN"? > > Does it mean that we can't develop a technology which is also usable in > the PSTN? For example, does it mean we can't select IKES as part of the > STIR solution, because the IKES draft also describes how to perform > validation in SS7, instead of just in SIP? Does it mean if I want to > propose IKES, I need to pull out the SS7-related content? > > I asked what the rationale was because usually what happens is an IESG > member raises some concern about something, and addressing the concern > results in such text getting added to a charter with the intention of > preventing something bad from happening in the WG... but the IESG review > page for the STIR charter doesn't show anything about that for this case. > > -hadriel > > The concern here was that some other organization (like ITU or 3GPP) could get confused that we were going to, say, develop some new "mega-UUIE" extension of SS7. I think everyone here agrees that we're don't want to change the PSTN, but we might want to use it. IKES is clearly close to the border line, but ISTM that it's on the right side. It doesn't change the POTS protocols, it just uses them, and says how to compare the authentication data to what is in SS7. The same would probably be true of OOB solutions that want to compare things to elements of a PSTN call. The updated draft I just posted incorporates Henning's suggestion: """ It is important to note that while the main focus of this working group is telephone numbers, the STIR working group will not develop any technologies based on circuit-switched technologies. """ Does that make any more sense? --Richard > > On Aug 19, 2013, at 12:05 PM, Hadriel Kaplan > wrote: > > > > > I don't know what this means: > > It is important to note that while the main focus of this working > group > > is telephone numbers, the STIR working group will not develop any > > technologies based on the PSTN. > > > > What was the rationale behind adding that, and what was the intent? > > > > -hadriel > > > > > > On Aug 19, 2013, at 10:53 AM, Richard Barnes wrote: > > > >> Dear STIR, > >> > >> In response to some comments from the IESG, we've made a few changes to > the STIR charter. The new proposed text has been uploaded to the > datatracker: > >> > >> Diff here: > >> < > http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/charter/charter-ietf-stir-00-01.txt&url2=http://www.ietf.org/charter/charter-ietf-stir-00-03.txt > > > >> > >> Please reply to this message by Wednesday, 21 Aug if you have any > issues with these changes. > >> > >> Thanks, > >> --Richard > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > --e89a8ff1c0248175cf04e4628e49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Aug 19, 2013 at 2:51 PM, Hadriel Kaplan &= lt;hadriel.k= aplan@oracle.com> wrote:

[I got some off-list comments on my question, so sending a clarification to= the list]

To be clear, I literally don't know what that text means in terms of it= s English meaning as it relates to this WG-to-be.
What does it mean to "not develop any technologies based on the PSTN&q= uot;?

Does it mean that we can't develop a technology which is also usable in= the PSTN? =A0For example, does it mean we can't select IKES as part of= the STIR solution, because the IKES draft also describes how to perform va= lidation in SS7, instead of just in SIP? =A0Does it mean if I want to propo= se IKES, I need to pull out the SS7-related content?

I asked what the rationale was because usually what happens is an IESG memb= er raises some concern about something, and addressing the concern results = in such text getting added to a charter with the intention of preventing so= mething bad from happening in the WG... but the IESG review page for the ST= IR charter doesn't show anything about that for this case.

-hadriel


The concern here was that some other organization (li= ke ITU or 3GPP) could get confused that we were going to, say, develop some= new "mega-UUIE" extension of SS7. =A0I think everyone here agree= s that we're don't want to change the PSTN, but we might want to us= e it.

IKES is clearly close to the border line, but ISTM that= it's on the right side. =A0It doesn't change the POTS protocols, i= t just uses them, and says how to compare the authentication data to what i= s in SS7. =A0The same would probably be true of OOB solutions that want to = compare things to elements of a PSTN call.

The updated draft I just posted incorporates Henning= 9;s suggestion:
"""
It is important= to note that while the main focus of this working group=A0
is te= lephone numbers, the STIR working group will not develop any=A0
technologies based on circuit-switched technologies.
&= quot;""

Does that make any more sense? = =A0

--Richard


=A0

On Aug 19, 2013, at 12:05 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

>
> I don't know what this means:
> =A0 =A0 =A0 It is important to note that while the main focus of this = working group
> =A0 =A0 =A0 is telephone numbers, the STIR working group will not deve= lop any
> =A0 =A0 =A0 technologies based on the PSTN.
>
> What was the rationale behind adding that, and what was the intent? >
> -hadriel
>
>
> On Aug 19, 2013, at 10:53 AM, Richard Barnes <rlb@ipv.sx> wrote:=
>
>> Dear STIR,
>>
>> In response to some comments from the IESG, we've made a few c= hanges to the STIR charter. The new proposed text has been uploaded to the = datatracker:
>> <https://datatracker.ietf.org/doc/charter-ietf-stir/= >
>> Diff here:
>> <http://www.= ietf.org/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.ietf.org/charter/charter-ie= tf-stir-00-01.txt&url2=3Dhttp://www.ietf.org/charter/charter-ietf-stir-= 00-03.txt>
>>
>> Please reply to this message by Wednesday, 21 Aug if you have any = issues with these changes.
>>
>> Thanks,
>> --Richard
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


--e89a8ff1c0248175cf04e4628e49-- From kent@bbn.com Tue Aug 20 08:24:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661EC11E822F for ; Tue, 20 Aug 2013 08:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9gHwI4oRF1z for ; Tue, 20 Aug 2013 08:23:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4649211E8229 for ; Tue, 20 Aug 2013 08:23:54 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49276) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBnmh-000CgT-5S; Tue, 20 Aug 2013 11:23:51 -0400 Message-ID: <52138A07.3080800@bbn.com> Date: Tue, 20 Aug 2013 11:23:51 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org List" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Brian Rosen Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:24:01 -0000 I would expect swindlers to find providers in locales where checks are not so stringent, to facilitate fraud, with some minimal level of plausible deniability. We have seen this happen in the web site cert arena for some time. Also, Acme Plumber in one city vs. Acme Plumbing in some other city is a legitimate distinction, but one that probably would be irrelevant if a called party is led to believe that a textual caller ID is reliable, as some suggest. Steve From hadriel.kaplan@oracle.com Tue Aug 20 08:37:08 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672D621F9AA9 for ; Tue, 20 Aug 2013 08:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQnpdEPRTt7Q for ; Tue, 20 Aug 2013 08:36:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9C23121F9A99 for ; Tue, 20 Aug 2013 08:36:51 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7KFaoRm006263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 15:36:50 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KFan97007459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 15:36:50 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KFansn014138; Tue, 20 Aug 2013 15:36:49 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Aug 2013 08:36:49 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 20 Aug 2013 11:36:47 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <555AC740-B6D3-49F1-BE7B-73AABCB1655F@oracle.com> To: Richard Barnes X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org List" Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:37:13 -0000 On Aug 20, 2013, at 11:17 AM, Richard Barnes wrote: > The updated draft I just posted incorporates Henning's suggestion: > """ > It is important to note that while the main focus of this working group > is telephone numbers, the STIR working group will not develop any > technologies based on circuit-switched technologies. > """ > > Does that make any more sense? No, other than to imply we won't base our technology on ATM. ;) I think what you really want to say is this: It is important to note that while the main focus of this working group is telephone numbers, the STIR working group will not develop any mechanisms that require changes to circuit-switched technologies. -hadriel From rlb@ipv.sx Tue Aug 20 08:41:12 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B875E11E8100 for ; Tue, 20 Aug 2013 08:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAzZbKnzGFqI for ; Tue, 20 Aug 2013 08:41:07 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id D803411E811E for ; Tue, 20 Aug 2013 08:41:06 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l20so1085657oag.17 for ; Tue, 20 Aug 2013 08:41:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NoY9bSxG4jqOXPpUxnuP9gVKOeCX3XosPtUppqE83lI=; b=PRp5MPHMmN7816/mSFvoARt7agcClTaqv8x03idPlywNgZi+92XhAJ5JdVhu1ao65A I70AD27PQPvcvi/EDonVReLShWsNidiClrhzEEF12WkjYiyR77FVc5ktbd1G9DVIzE8R 3SpM3us04zRYFwlpxmv9e95IXuRmZvwO4guKMIrLEJOGlj0eIIMTVNieyhmaxAkl5/az xY25veVy40G/bjlRmdxzsfPn6d3IyxCEU/yquSgOJ6wTb3PJuVXOEY2ANI/ypPv6fL5m 8MgooJ8QF19oM8Fxk7OLzUS9U67bsEimcyNC89xHbQPteUmpn0eyE+UzUBe8DXqTl2gw PFfw== X-Gm-Message-State: ALoCoQnUXxo4KdAScUSJcwdhccUxxW10iln1xg9+C68dFtH1RK9B/2KMFT8jbgocrktY15iAc4lg MIME-Version: 1.0 X-Received: by 10.60.145.241 with SMTP id sx17mr2289059oeb.57.1377013266285; Tue, 20 Aug 2013 08:41:06 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Tue, 20 Aug 2013 08:41:06 -0700 (PDT) X-Originating-IP: [192.1.51.54] In-Reply-To: References: <555AC740-B6D3-49F1-BE7B-73AABCB1655F@oracle.com> Date: Tue, 20 Aug 2013 11:41:06 -0400 Message-ID: From: Richard Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7b5d474a96967704e462e200 Cc: "stir@ietf.org List" Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:41:12 -0000 --047d7b5d474a96967704e462e200 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 20, 2013 at 11:36 AM, Hadriel Kaplan wrote: > > On Aug 20, 2013, at 11:17 AM, Richard Barnes wrote: > > > The updated draft I just posted incorporates Henning's suggestion: > > """ > > It is important to note that while the main focus of this working group > > is telephone numbers, the STIR working group will not develop any > > technologies based on circuit-switched technologies. > > """ > > > > Does that make any more sense? > > No, other than to imply we won't base our technology on ATM. ;) > > I think what you really want to say is this: > It is important to note that while the main focus of this working group > is telephone numbers, the STIR working group will not develop any > mechanisms that require changes to circuit-switched technologies. > > -hadriel > > That works for me. Unless people reply negatively here, I'll plan to include it. --Richard --047d7b5d474a96967704e462e200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 20, 2013 at 11:36 AM, Hadriel Kaplan = <hadriel.= kaplan@oracle.com> wrote:

On Aug 20, 2013, at 11:17 AM, Richard Barnes <rlb@ipv.sx> wrote:

> The updated draft I just posted incorporates Henning's suggestion:=
> """
> It is important to note that while the main focus of this working grou= p
> is telephone numbers, the STIR working group will not develop any
> technologies based on circuit-switched technologies.
> """
>
> Does that make any more sense?

No, other than to imply we won't base our technology on ATM. =A0;= )

I think what you really want to say is this:
=A0 =A0 It is important to note that while the main focus= of this working group
=A0 =A0 is telephone numbers, the STIR working group will not develop any
=A0 =A0 mechanisms that require changes to circuit-switched technolog= ies.

-hadriel


That works for me. =A0Un= less people reply negatively here, I'll plan to include it.
<= br>
--Richard =A0

--047d7b5d474a96967704e462e200-- From hadriel.kaplan@oracle.com Tue Aug 20 08:41:38 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651AA11E8247 for ; Tue, 20 Aug 2013 08:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erdZJiKN3Ygk for ; Tue, 20 Aug 2013 08:41:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id EAE8B11E811E for ; Tue, 20 Aug 2013 08:41:32 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7KFfVTo012474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 15:41:32 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KFfVJS026801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 15:41:31 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KFfVRd026795; Tue, 20 Aug 2013 15:41:31 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Aug 2013 08:41:31 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 20 Aug 2013 11:41:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F11116B-E3A6-4D81-80E2-FC349226168B@oracle.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:41:38 -0000 This latest version has the following changed text: Expansion of the authorization mechanism to identities using the user@domain form is out of scope. The work of this group is limited = to developing a solution for telephone numbers. I'd always assumed that something being "out of scope" didn't mean you = couldn't also solve that problem at the same time with the same = mechanism if you got it "for free". But the above second sentence = actually prevents it, I think. I mention this because IKES, CIDER, and draft-4474bis happen to also = cover/apply-to 'user@domain' type of identities. -hadriel On Aug 20, 2013, at 11:15 AM, Richard Barnes wrote: > New version with a few more edits: > > = >=20 >=20 > On Mon, Aug 19, 2013 at 10:53 AM, Richard Barnes wrote: > Dear STIR, >=20 > In response to some comments from the IESG, we've made a few changes = to the STIR charter. The new proposed text has been uploaded to the = datatracker: > > Diff here: > = >=20 > Please reply to this message by Wednesday, 21 Aug if you have any = issues with these changes. >=20 > Thanks, > --Richard >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Tue Aug 20 08:47:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5775811E811E for ; Tue, 20 Aug 2013 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.276 X-Spam-Level: X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4bT4ptSkcog for ; Tue, 20 Aug 2013 08:47:19 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id B5AB621F9C47 for ; Tue, 20 Aug 2013 08:47:18 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id F0X71m0031vXlb85B3nH8R; Tue, 20 Aug 2013 15:47:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id F3nH1m00M3ZTu2S3d3nHpG; Tue, 20 Aug 2013 15:47:17 +0000 Message-ID: <52138F84.3040206@alum.mit.edu> Date: Tue, 20 Aug 2013 11:47:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58 D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <46EB9BA5-BB66-4BE3-BA8C-5FB38632263B@edvina.net> In-Reply-To: <46EB9BA5-BB66-4BE3-BA8C-5FB38632263B@edvina.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377013637; bh=vOB/41xTW5P8ehg8Hm0Sh/TC4t0yQWfmbG9b7sRNWAc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lKnZC9Mqo6eQsDx/wstP9jXFcX+2PuaMnbJtIgiO7CrdPnIXgFQaLmnhVnEfa1JYb cVHZIQccyH4Ft3sjt3xwvHvF1JoMISZNZzaQAVPQ6WQ/JTR9er2caO5QjyH3Nd7q0t 9jjl+sPoUL8wikdzwuxgJ0LhuoMdeUzUg25o385Y40pHNXokGkOgffaHlSFWb8iH5I pBPubMXyHd6wI9jBr51VrXCph8rTTcJmJDrLGw0MZXiCy/Ss5f3slShxwASDvTYH8l TSHz/UOGCQ409AoytoQa9bst0TLpa4YsuVUSXhLaGMOTUAH0gSXIzRHunlsQApvxWA wbnjDYyWy2B+g== Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:47:23 -0000 I suspect that private providers of calling name might satisfy the need. E.g., something similar to Google lookup of the phone number. I can imagine some phone apps coming along for this. Exactly what information is provided, and where it comes from will vary. But then people will know what to expect, and not, based on reviews of the app. This won't solve the problem for companies that want the name to say something special. But signing the From can serve that purpose. And an app can display the caller's assertion along with whatever else it can find that doesn't depend on trusting the caller. Of course this won't work for legacy phones, but that is a problem that will go away with time. Maybe the existing CNAM DBs will continue to serve those in the meantime. Thanks, Paul On 8/20/13 2:40 AM, Olle E. Johansson wrote: > Excuse me, but I get a PKI and enum feeling when reading this. Trying to > get the TRUE caller ID name from 3rd party sources will delay this > process forever. There are tons of issues to handle here, not forgetting > privacy. > > Do we really need the honest-to-god true legal names or do we need to > trace who assured the name? > > If someone fakes a name we need to be able to stop that from happening > again, we need a non-repudiation scheme so we can find who did it. > > I see a lot of cases where a company wants to modify caller ID names for > the same number and not use the legal name. "Edvina Support" calling, > "Edvina Order dept, Elena" etc etc. I see very few cases where I need a > full legal and digital identity in the caller ID name - and if that's > needed, let's point to S/MIME (ducks). > > In addition, we also have a system in Sweden where the same legal > identity can have multiple company names registred... > > /O > > > > 19 aug 2013 kl. 20:05 skrev Henning Schulzrinne > >: > >> As you say, there are currently no databases that associate numbers >> with corporate records, but such association doesn’t seem all that >> hard, assuming that the owners of those databases see a business >> opportunity. They are, like Steve says, authoritative for the business >> name. They also have known contact points at those corporations, so >> impersonation is a lot harder. >> The model would be that the existing business record (e.g., credit >> reporting or state agencies) allow their registered entities to add >> numbers to the record. They wouldn’t need to add all their numbers – >> the numbers used for outbound calls to customers would be sufficient, >> not every desk phone of backoffice staff with no customer contact. For >> large entities such as most banks, they could also simply provide a >> public key in the record, indicating that every number signed with the >> corresponding private key is theirs. >> The receiving entity queries the database with the name, number or >> public key. >> Yes, it’s largely a separate effort, but we do want to most likely tie >> the crypto credentials, so discussing how they might work together >> seems helpful. >> *From:*Brian Rosen [mailto:br@brianrosen.net ] >> *Sent:*Monday, August 19, 2013 1:56 PM >> *To:*Henning Schulzrinne >> *Cc:*Dwight, Timothy M (Tim); Hadriel Kaplan;stir@ietf.org >> List >> *Subject:*Re: [stir] Early Homework (was Re: Moving from BOF to Charter) >> There are accurate databases for human names in most developed >> countries. Further, the databases you refer to would not have the >> information needed to associate a business name with all of the >> numbers that the business might use. There are databases that have >> much of the information, but would likely need some enhancement to >> have ALL of the possible numbers. >> The issue I think we need to deal with has two aspects: >> 1. The entity asserting the name can't really claim authority because >> there is no delegation chain for "John Smith" or "World Wide >> Widgets". There are third parties that can assert some level of >> assurance that the name goes with the number. >> 2. The assurance you get is not binary. There is a score. >> So, I think the way this would work is that a third party asserts a >> likelihood score that the name asserted in the signaling is valid. >> This would work the best if the originating service provider asserted >> the score. The reason why is that the score is better the more >> information is known. If the originating SP provides the assurance >> service information like service address, or other identifying >> information, the confidence is better, and the score can be higher. >> If there are only a few assurance services, their credentials could >> be known by the terminating end, and some form of the score signed by >> the service could be attached to the call and verified at the >> termination. The terminating end could use an assurance service of >> its own choosing, but it would likely have only the name and number as >> input, and thus have a limited score range to work with. >> I do think that if there was a notion of a category (bank, insurance >> company, doctor) included in the data, possibly with its own score, >> that would help. >> I think this is outside the charter. We can either decide to work on >> this later here in stir, or start a parallel effort. >> Brian >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From rlb@ipv.sx Tue Aug 20 08:54:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F7C21F9CE9 for ; Tue, 20 Aug 2013 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6Y6Pt1bAulK for ; Tue, 20 Aug 2013 08:54:09 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5315021F9CB5 for ; Tue, 20 Aug 2013 08:54:08 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so1136389oag.30 for ; Tue, 20 Aug 2013 08:54:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4VW6RzY/uNrkROFwXWs2yQimOQ07arcaPYgg/LA9XKM=; b=O4yCwBpfP0jEtg4Vj0+DtdjAAcqy5okNExqvJ2K27ihuMqLj41nB/fdXVURVrblWiw lBK1KJ1KcLKy7Qvdm2IGT+/Ok6FA2X6+IapVMIu+yHOqdbTpRv4Uzch0offa1UmrLj/E Ig75lvMNcovK7ffTlAGL4PLQYbOnExUhlJ/U94F0Kwq0fp+j1DyYuWoxZkZdoLyaFS/W RlX2V0zTdRzs+wa8FK4wXB+xqOl+OU5wK5UlyUDWF1rZ1++8NRKCsnxQZzfCNNBkSZSR PINGs/fFATUx1VeMEIwCf2tci5Z64fBm/BQvk/JpDgSJUWGrzRLzMi17Vc6htfK4JiCT NC8Q== X-Gm-Message-State: ALoCoQl8uZqOIp7krjq5I44PgeyJKGeUQnUuZRfvt+J6o5bxobBIsCL30uT6eBdsaSGaCHfYkdP9 MIME-Version: 1.0 X-Received: by 10.60.145.241 with SMTP id sx17mr2363523oeb.57.1377014046747; Tue, 20 Aug 2013 08:54:06 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Tue, 20 Aug 2013 08:54:06 -0700 (PDT) X-Originating-IP: [192.1.48.2] In-Reply-To: <3F11116B-E3A6-4D81-80E2-FC349226168B@oracle.com> References: <3F11116B-E3A6-4D81-80E2-FC349226168B@oracle.com> Date: Tue, 20 Aug 2013 11:54:06 -0400 Message-ID: From: Richard Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7b5d474a1b77af04e4631159 Cc: "stir@ietf.org" Subject: Re: [stir] Charter revisions after IESG review X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:54:15 -0000 --047d7b5d474a1b77af04e4631159 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 20, 2013 at 11:41 AM, Hadriel Kaplan wrote: > > This latest version has the following changed text: > Expansion of the authorization mechanism to identities using the > user@domain form is out of scope. The work of this group is limited > to > developing a solution for telephone numbers. > > I'd always assumed that something being "out of scope" didn't mean you > couldn't also solve that problem at the same time with the same mechanism > if you got it "for free". But the above second sentence actually prevents > it, I think. > > I mention this because IKES, CIDER, and draft-4474bis happen to also > cover/apply-to 'user@domain' type of identities. > > -hadriel I don't think that should rule out "for free". But if there's going to be significant effort expended, we would want a re-charter. --Richard > > On Aug 20, 2013, at 11:15 AM, Richard Barnes wrote: > > > New version with a few more edits: > > > > < > http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/charter/charter-ietf-stir-00-03.txt&url2=http://www.ietf.org/charter/charter-ietf-stir-00-04.txt > > > > > > > > On Mon, Aug 19, 2013 at 10:53 AM, Richard Barnes wrote: > > Dear STIR, > > > > In response to some comments from the IESG, we've made a few changes to > the STIR charter. The new proposed text has been uploaded to the > datatracker: > > > > Diff here: > > < > http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/charter/charter-ietf-stir-00-01.txt&url2=http://www.ietf.org/charter/charter-ietf-stir-00-03.txt > > > > > > Please reply to this message by Wednesday, 21 Aug if you have any issues > with these changes. > > > > Thanks, > > --Richard > > > > > > > > > > > > > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > --047d7b5d474a1b77af04e4631159 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 20, 2013 at 11:41 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

This latest version has the following changed text:
=A0 =A0 Expansion of the authorization mechanism to identities using the =A0 =A0 user@domain form is out of scope. =A0The work of this group is limi= ted to
=A0 =A0 developing a solution for telephone numbers.

I'd always assumed that something being "out of scope" didn&#= 39;t mean you couldn't also solve that problem at the same time with th= e same mechanism if you got it "for free". =A0But the above secon= d sentence actually prevents it, I think.

I mention this because IKES, CIDER, and draft-4474bis happen to also cover/= apply-to 'user@domain' type of identities.

-hadriel

I don't think th= at should rule out "for free". =A0But if there's going to be = significant effort expended, we would want a re-charter.

--Richard

=A0

On Aug 20, 2013, at 11:15 AM, Richard Barnes <rlb@ipv.sx> wrote:

> New version with a few more edits:
> <https://datatracker.ietf.org/doc/charter-ietf-stir/>=
> <http://www.ietf= .org/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.ietf.org/charter/charter-ietf-s= tir-00-03.txt&url2=3Dhttp://www.ietf.org/charter/charter-ietf-stir-00-0= 4.txt>
>
>
> On Mon, Aug 19, 2013 at 10:53 AM, Richard Barnes <rlb@ipv.sx> wr= ote:
> Dear STIR,
>
> In response to some comments from the IESG, we've made a few chang= es to the STIR charter. The new proposed text has been uploaded to the data= tracker:
> <https://datatracker.ietf.org/doc/charter-ietf-stir/>=
> Diff here:
> <http://www.ietf= .org/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.ietf.org/charter/charter-ietf-s= tir-00-01.txt&url2=3Dhttp://www.ietf.org/charter/charter-ietf-stir-00-0= 3.txt>
>
> Please reply to this message by Wednesday, 21 Aug if you have any issu= es with these changes.
>
> Thanks,
> --Richard
>
>
>
>
>
>
>
> __________________= _____________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


--047d7b5d474a1b77af04e4631159-- From pkyzivat@alum.mit.edu Tue Aug 20 08:57:05 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C003C21F9B10 for ; Tue, 20 Aug 2013 08:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=1.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2+Gr8eB3Psy for ; Tue, 20 Aug 2013 08:56:58 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 83F5E21F848A for ; Tue, 20 Aug 2013 08:56:49 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta01.westchester.pa.mail.comcast.net with comcast id F2oW1m0041HzFnQ513wpUu; Tue, 20 Aug 2013 15:56:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id F3wo1m01G3ZTu2S3a3wodJ; Tue, 20 Aug 2013 15:56:49 +0000 Message-ID: <521391BF.3030507@alum.mit.edu> Date: Tue, 20 Aug 2013 11:56:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> In-Reply-To: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377014209; bh=h+okDwOdejmcQEu8VvC4NnOycdcZ1CgCW4kh128kgxo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nRRd0bRwZZX1sfFKEan3iBPg9u7HHQ3gCHDBlmkU+3L4IqDcyOQ8xPVGHemdxV3JM DdcE1KLENtRNp/kloCfh9Y12hOlWmrRgDP+NG2hYQAJXVS8oAIxbZ+7RzywLgHgBsw 7w1zjYdrUaY29DihaiFouea1QxQC3csvt/2aqeuXChBxsUWzVlTURgsNLMsEQMQ3F2 zWkgIq9EIwVudY/h1Ho6mnkH/wvweXgzqkTpQMqAMgCJDEXFWm//cIX/lcCz1Qmehp dqUOONYvqo54y3saKUd/tcjXjJEmxx3xd4HOagbCceoqd/fYb4RNOzenGvt9GdgjhK sQsEFa+epIxqg== Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:57:05 -0000 Richard, This letter says: "two robocall screening technologies were discussed in some detail, one of which has been in operation for six years." What technologies were these? Thanks, Paul On 8/19/13 4:21 PM, Richard Shockey wrote: > http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf > > FYI … > > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > skype-linkedin-facebook: rshockey101 > http//www.sipforum.org > > "Money is the answer, what is the question?" tm > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From Henning.Schulzrinne@fcc.gov Tue Aug 20 09:10:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443F311E823E for ; Tue, 20 Aug 2013 09:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+S+MXSgYoje for ; Tue, 20 Aug 2013 09:09:47 -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 A14CB11E8123 for ; Tue, 20 Aug 2013 09:09:45 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Stephen Kent' Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKlscXjeM0mT0yCJxP1MuZSzpmVCJwAgAA2EgCAAA1WAIAAByMA//+9NbCAAZhJ4IAAtYSAgAAwhgCAAGoAgIAAIfKAgASzCVCAAE4lAIAACBEA///ELRCAAZungP//yI8w Date: Tue, 20 Aug 2013 16:09:43 +0000 References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <52138A07.3080800@bbn.com> In-Reply-To: <52138A07.3080800@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org List" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Brian Rosen Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 16:10:02 -0000 I just don't see name confusion among legitimate entities as a problem for = consumers. This is only a problem if ACME Plumbing Chicago somehow pretends= to be my local NJ ACME Plumbing (with a different owner). Not very likely.= The problem we're trying to solve is that some random entity can pretend t= o be ACME Plumbing without a corresponding corporate registration. To repeat myself: once you can provide additional information (location, li= ne of business), the confusion problem drops significantly, as legitimate e= ntities generally have incentives to differentiate themselves within their = locality and line of business, even if trademark law doesn't force the issu= e. Yes, there's a trust problem with the database, but we discussed that alrea= dy - some recipients will decide not to trust the Nigerian Business Certifi= cation agency. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Tuesday, August 20, 2013 11:24 AM To: Henning Schulzrinne Cc: Brian Rosen; stir@ietf.org List; Hadriel Kaplan; Dwight, Timothy M (Tim= ) Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) I would expect swindlers to find providers in locales where checks are not = so stringent, to facilitate fraud, with some minimal level of plausible den= iability.=20 We have seen this happen in the web site cert arena for some time. Also, Acme Plumber in one city vs. Acme Plumbing in some other city is a le= gitimate distinction, but one that probably would be irrelevant if a called= party is led to believe that a textual caller ID is reliable, as some sugg= est. Steve From br@brianrosen.net Tue Aug 20 09:10:37 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE1A11E823E for ; Tue, 20 Aug 2013 09:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.075 X-Spam-Level: X-Spam-Status: No, score=-101.075 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_BIZOP=0.7, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfs0VnsSl3GE for ; Tue, 20 Aug 2013 09:10:23 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id AD5A811E80E1 for ; Tue, 20 Aug 2013 09:10:23 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so597899pbb.6 for ; Tue, 20 Aug 2013 09:10:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vIMxd9z7aA5dQX+PD9fNycBGhOUUbnJOk9J336OpGDg=; b=co2/P7ytRxp8hxXlFIHO72Em4JeMWtwD3uaGCExJGBURfH0lHj8qWapes5gJZzX/U3 uRjhuPGdrFIEGHVBD2hwLFIJb9dZxHKqhDDyKJf4q+IayYUtEz9lyzHM5WzPl/7k6E+q Z84HmVH3I9/WazO8iZJcl/V18zxjM+8V5lrgmZHsN/ZEJO29rFMDYZ9+SaNLx9dSco/w wUefPLjXVIa7730mbW3QNM2YEoDD9B7PReN91YrxczRMtxMzV4BkBmxrsP5BIvuZEhEM 9YpwU1F/Uf52Zv51FUoIy+iGghP6tEfaD4gvRZNmv76yT/SN30GPsRZwv9xYipnCNPRb IbNw== X-Gm-Message-State: ALoCoQmFZzr5FNQD4brEhfyHra6bnBTXGvvfeiVx2GETtSK2R4UgauwQpt1uS/JyaDEfygGvjmJF MIME-Version: 1.0 X-Received: by 10.66.250.138 with SMTP id zc10mr4802652pac.72.1377015023026; Tue, 20 Aug 2013 09:10:23 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 20 Aug 2013 09:10:22 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <52138F84.3040206@alum.mit.edu> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <46EB9BA5-BB66-4BE3-BA8C-5FB38632263B@edvina.net> <52138F84.3040206@alum.mit.edu> Date: Tue, 20 Aug 2013 12:10:22 -0400 Message-ID: From: Brian Rosen To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b15aca54c73aa04e4634b28 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 16:10:38 -0000 --047d7b15aca54c73aa04e4634b28 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If you do all of the processing at the termination end, it's okay, but it could be better. This is how the Neustar CNAM service works. We have a database, the termination carrier can query it with the phone number and get a name. It's not dependent on the originating SP. It would be better if this validation was done at the origination side, because the originating carrier has more information about the customer that can be used to improve the score. It also would deal with the desire to have some control on the actual presentation, and has a faster start up (when you do it at the termination side, adding a new record takes more time, because the sources for the data have significant lag). The downside is that the service the originating carrier uses to validate might not be as stringent as the called party wishes to have. It's always possible to do both, or to decide to use a validation service on the terminating side if the service used on the originating side isn't good enough for the called party. Doing validation on the originating side is a hybrid of the two schemes used today. You apply validation to the claimed name at the originating SP and get a score. You carry that through the network. I think that would work quite a bit better than an unvalidated name carried through the network and all validation on the terminating side. Brian On Tue, Aug 20, 2013 at 11:47 AM, Paul Kyzivat wrote= : > I suspect that private providers of calling name might satisfy the need. > E.g., something similar to Google lookup of the phone number. I can imagi= ne > some phone apps coming along for this. Exactly what information is > provided, and where it comes from will vary. But then people will know wh= at > to expect, and not, based on reviews of the app. > > This won't solve the problem for companies that want the name to say > something special. But signing the From can serve that purpose. And an ap= p > can display the caller's assertion along with whatever else it can find > that doesn't depend on trusting the caller. > > Of course this won't work for legacy phones, but that is a problem that > will go away with time. Maybe the existing CNAM DBs will continue to serv= e > those in the meantime. > > Thanks, > Paul > > > On 8/20/13 2:40 AM, Olle E. Johansson wrote: > >> Excuse me, but I get a PKI and enum feeling when reading this. Trying to >> get the TRUE caller ID name from 3rd party sources will delay this >> process forever. There are tons of issues to handle here, not forgetting >> privacy. >> >> Do we really need the honest-to-god true legal names or do we need to >> trace who assured the name? >> >> If someone fakes a name we need to be able to stop that from happening >> again, we need a non-repudiation scheme so we can find who did it. >> >> I see a lot of cases where a company wants to modify caller ID names for >> the same number and not use the legal name. "Edvina Support" calling, >> "Edvina Order dept, Elena" etc etc. I see very few cases where I need a >> full legal and digital identity in the caller ID name - and if that's >> needed, let's point to S/MIME (ducks). >> >> In addition, we also have a system in Sweden where the same legal >> identity can have multiple company names registred... >> >> /O >> >> >> >> 19 aug 2013 kl. 20:05 skrev Henning Schulzrinne >> >> >>: >> >> As you say, there are currently no databases that associate numbers >>> with corporate records, but such association doesn=92t seem all that >>> hard, assuming that the owners of those databases see a business >>> opportunity. They are, like Steve says, authoritative for the business >>> name. They also have known contact points at those corporations, so >>> impersonation is a lot harder. >>> The model would be that the existing business record (e.g., credit >>> reporting or state agencies) allow their registered entities to add >>> numbers to the record. They wouldn=92t need to add all their numbers = =96 >>> the numbers used for outbound calls to customers would be sufficient, >>> not every desk phone of backoffice staff with no customer contact. For >>> large entities such as most banks, they could also simply provide a >>> public key in the record, indicating that every number signed with the >>> corresponding private key is theirs. >>> The receiving entity queries the database with the name, number or >>> public key. >>> Yes, it=92s largely a separate effort, but we do want to most likely ti= e >>> the crypto credentials, so discussing how they might work together >>> seems helpful. >>> *From:*Brian Rosen [mailto:br@brianrosen.net ] >>> *Sent:*Monday, August 19, 2013 1:56 PM >>> *To:*Henning Schulzrinne >>> *Cc:*Dwight, Timothy M (Tim); Hadriel Kaplan;stir@ietf.org >>> List >>> *Subject:*Re: [stir] Early Homework (was Re: Moving from BOF to Charter= ) >>> >>> There are accurate databases for human names in most developed >>> countries. Further, the databases you refer to would not have the >>> information needed to associate a business name with all of the >>> numbers that the business might use. There are databases that have >>> much of the information, but would likely need some enhancement to >>> have ALL of the possible numbers. >>> The issue I think we need to deal with has two aspects: >>> 1. The entity asserting the name can't really claim authority because >>> there is no delegation chain for "John Smith" or "World Wide >>> Widgets". There are third parties that can assert some level of >>> assurance that the name goes with the number. >>> 2. The assurance you get is not binary. There is a score. >>> So, I think the way this would work is that a third party asserts a >>> likelihood score that the name asserted in the signaling is valid. >>> This would work the best if the originating service provider asserted >>> the score. The reason why is that the score is better the more >>> information is known. If the originating SP provides the assurance >>> service information like service address, or other identifying >>> information, the confidence is better, and the score can be higher. >>> If there are only a few assurance services, their credentials could >>> be known by the terminating end, and some form of the score signed by >>> the service could be attached to the call and verified at the >>> termination. The terminating end could use an assurance service of >>> its own choosing, but it would likely have only the name and number as >>> input, and thus have a limited score range to work with. >>> I do think that if there was a notion of a category (bank, insurance >>> company, doctor) included in the data, possibly with its own score, >>> that would help. >>> I think this is outside the charter. We can either decide to work on >>> this later here in stir, or start a parallel effort. >>> Brian >>> ______________________________**_________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/**listinfo/stir >>> >> >> >> >> ______________________________**_________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/**listinfo/stir >> >> > ______________________________**_________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/**listinfo/stir > --047d7b15aca54c73aa04e4634b28 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
If you do all of the processing at the termination end, it= 's okay, but it could be better. =A0This is how the Neustar CNAM servic= e works. =A0We have a database, the termination carrier can query it with t= he phone number and get a name. =A0It's not dependent on the originatin= g SP.

It would be better if this validation was done at the origin= ation side, because the originating carrier has more information about the = customer that can be used to improve the score. =A0It also would deal with = the desire to have some control on the actual presentation, and has a faste= r start up (when you do it at the termination side, adding a new record tak= es more time, because the sources for the data have significant lag). =A0Th= e downside is that the service the originating carrier uses to validate mig= ht not be as stringent as the called party wishes to have. =A0It's alwa= ys possible to do both, or to decide to use a validation service on the ter= minating side if the service used on the originating side isn't good en= ough for the called party.

Doing validation on the originating side is a hybrid of= the two schemes used today. =A0You apply validation to the claimed name at= the originating SP and get a score. =A0You carry that through the network.= =A0I think that would work quite a bit better than an unvalidated name car= ried through the network and all validation on the terminating side.

Brian


On Tue, Aug 20, 2013 at 11:47 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
I suspect that private providers of calling = name might satisfy the need. E.g., something similar to Google lookup of th= e phone number. I can imagine some phone apps coming along for this. Exactl= y what information is provided, and where it comes from will vary. But then= people will know what to expect, and not, based on reviews of the app.

This won't solve the problem for companies that want the name to say so= mething special. But signing the From can serve that purpose. And an app ca= n display the caller's assertion along with whatever else it can find t= hat doesn't depend on trusting the caller.

Of course this won't work for legacy phones, but that is a problem that= will go away with time. Maybe the existing CNAM DBs will continue to serve= those in the meantime.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 8/20/13 2:40 AM, Olle E. Johansson wrote:
Excuse me, but I get a PKI and enum feeling when reading this. Trying to get the TRUE caller ID name from 3rd party sources will delay this
process forever. There are tons of issues to handle here, not forgetting privacy.

Do we really need the honest-to-god true legal names or do we need to
trace who assured the name?

If someone fakes a name we need to be able to stop that from happening
again, we need a non-repudiation scheme so we can find who did it.

I see a lot of cases where a company wants to modify caller ID names for the same number and not use the legal name. "Edvina Support" call= ing,
"Edvina Order dept, Elena" etc etc. I see very few cases where I = need a
full legal and digital identity in the caller ID name - and if that's needed, let's point to S/MIME (ducks).

In addition, we also have a system in Sweden where the same legal
identity can have multiple company names registred...

/O



19 aug 2013 kl. 20:05 skrev Henning Schulzrinne
<Hennin= g.Schulzrinne@fcc.gov <mailto:Henning.Schulzrinne@fcc.gov>>:<= br>
As you say, there are currently no databases that associate numbers
with corporate records, but such association doesn=92t seem all that
hard, assuming that the owners of those databases see a business
opportunity. They are, like Steve says, authoritative for the business
name. They also have known contact points at those corporations, so
impersonation is a lot harder.
The model would be that the existing business record (e.g., credit
reporting or state agencies) allow their registered entities to add
numbers to the record. They wouldn=92t need to add all their numbers =96 the numbers used for outbound calls to customers would be sufficient,
not every desk phone of backoffice staff with no customer contact. For
large entities such as most banks, they could also simply provide a
public key in the record, indicating that every number signed with the
corresponding private key is theirs.
The receiving entity queries the database with the name, number or
public key.
Yes, it=92s largely a separate effort, but we do want to most likely tie the crypto credentials, so discussing how they might work together
seems helpful.
*From:*Brian Rosen [mailto:br@brianrosen.net <http://brianrosen.net>]
*Sent:*Monday, August 19, 2013 1:56 PM
*To:*Henning Schulzrinne
*Cc:*Dwight, Timothy M (Tim); Hadriel Kaplan;stir@ietf.org
<mailto:stir@ietf.org= >List
*Subject:*Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

There are accurate databases for human names in most developed
countries. =A0Further, the databases you refer to would not have the
information needed to associate a business name with all of the
numbers that the business might use. =A0There are databases that have
much of the information, but would likely need some enhancement to
have ALL of the possible numbers.
The issue I think we need to deal with has two aspects:
1. The entity asserting the name can't really claim authority because there is no delegation chain for "John Smith" =A0or "World W= ide
Widgets". =A0There are third parties that can assert some level of
assurance that the name goes with the number.
2. The assurance you get is not binary. =A0There is a score.
So, I think the way this would work is that a third party asserts a
likelihood score that the name asserted in the signaling is valid.
=A0This would work the best if the originating service provider asserted the score. =A0The reason why is that the score is better the more
information is known. =A0If the originating SP provides the assurance
service information like service address, or other identifying
information, the confidence is better, and the score can be higher.
=A0If there are only a few assurance services, their credentials could
be known by the terminating end, and some form of the score signed by
the service could be attached to the call and verified at the
termination. =A0The terminating end could use an assurance service of
its own choosing, but it would likely have only the name and number as
input, and thus have a limited score range to work with.
I do think that if there was a notion of a category (bank, insurance
company, doctor) included in the data, possibly with its own score,
that would help.
I think this is outside the charter. =A0We can either decide to work on
this later here in stir, or start a parallel effort.
Brian
_______________________________________________
stir mailing list
stir@ietf.or= g <mailto:stir@ie= tf.org>
ht= tps://www.ietf.org/mailman/listinfo/stir



_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--047d7b15aca54c73aa04e4634b28-- From hadriel.kaplan@oracle.com Tue Aug 20 09:12:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D2A11E8123 for ; Tue, 20 Aug 2013 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.478 X-Spam-Level: X-Spam-Status: No, score=-7.478 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6JE3FIRLDNf for ; Tue, 20 Aug 2013 09:12:27 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5A43B11E80E1 for ; Tue, 20 Aug 2013 09:12:21 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7KGCJSK014560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 16:12:19 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KGCILg001987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 16:12:19 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KGCIX4018790; Tue, 20 Aug 2013 16:12:18 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Aug 2013 09:12:18 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <521391BF.3030507@alum.mit.edu> Date: Tue, 20 Aug 2013 12:12:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> <521391BF.3030507@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 16:12:32 -0000 It was discussed in the FTC subcommittee hearing, for which the video = recording is available here: = http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRecord= _id=3Dc1eec086-3512-4182-ae63-d60e68f4a532 There was an email thread on this in STIR list starting here: http://www.ietf.org/mail-archive/web/stir/current/msg00762.html The two technologies discussed were Primus' TeleGuard, and Nomorobo. = The Primus one has been around for a while. Unfortunately without STIR both of those "technologies" are easily = defeat-able, afaict. -hadriel On Aug 20, 2013, at 11:56 AM, Paul Kyzivat = wrote: > Richard, >=20 > This letter says: "two robocall screening technologies were discussed = in some detail, one of which has been in operation for six years." >=20 > What technologies were these? >=20 > Thanks, > Paul >=20 > On 8/19/13 4:21 PM, Richard Shockey wrote: >> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf >>=20 >> FYI =85 >>=20 >> Richard Shockey >> Shockey Consulting >> Chairman of the Board of Directors SIP Forum >> PSTN Mobile: +1 703.593.2683 >> >> skype-linkedin-facebook: rshockey101 >> http//www.sipforum.org >>=20 >> "Money is the answer, what is the question?" tm >>=20 >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Tue Aug 20 09:42:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CD211E810E for ; Tue, 20 Aug 2013 09:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMSjrAcpeyyd for ; Tue, 20 Aug 2013 09:42:39 -0700 (PDT) Received: from oproxy5-pub.mail.unifiedlayer.com (oproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id F3FA211E8114 for ; Tue, 20 Aug 2013 09:42:38 -0700 (PDT) Received: (qmail 12320 invoked by uid 0); 20 Aug 2013 16:42:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy5.mail.unifiedlayer.com with SMTP; 20 Aug 2013 16:42:12 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=T1qscA86YqewIG3/Xgm6VC/rZPwAKeMm+TuCevsadm8=; b=nlLLadXVRVBlAmYtdGg7QYvHuUK2UNHpGpllJZzxAi0SX/uSwYqbFmmmqc3OkVjmKd9Rt9psWVyyfcBFKEMV9NomBql/YR42e6cZseuEfBxumRtuc12GJDumEPyu95gk; Received: from [71.114.100.16] (port=50716 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBp0V-0008Vo-0K; Tue, 20 Aug 2013 10:42:11 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> <521391BF.3030507@alum.mit.edu> <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> In-Reply-To: <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> Date: Tue, 20 Aug 2013 12:42:09 -0400 Message-ID: <00ec01ce9dc4$375bff90$a613feb0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHf/Sb7v1qQL7dRTIR00ecfBw42tAEVZP+vAdE7YkqZZFixYA== X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 16:42:43 -0000 Exactly ... essentially useless. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, August 20, 2013 12:12 PM To: Paul Kyzivat Cc: stir@ietf.org Subject: Re: [stir] Your DC newsletter of the day.... It was discussed in the FTC subcommittee hearing, for which the video recording is available here: http://www.commerce.senate.gov/public/index.cfm?p=Hearings&ContentRecord_id= c1eec086-3512-4182-ae63-d60e68f4a532 There was an email thread on this in STIR list starting here: http://www.ietf.org/mail-archive/web/stir/current/msg00762.html The two technologies discussed were Primus' TeleGuard, and Nomorobo. The Primus one has been around for a while. Unfortunately without STIR both of those "technologies" are easily defeat-able, afaict. -hadriel On Aug 20, 2013, at 11:56 AM, Paul Kyzivat wrote: > Richard, > > This letter says: "two robocall screening technologies were discussed in some detail, one of which has been in operation for six years." > > What technologies were these? > > Thanks, > Paul > > On 8/19/13 4:21 PM, Richard Shockey wrote: >> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf >> >> FYI . >> >> Richard Shockey >> Shockey Consulting >> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 >> 703.593.2683 >> skype-linkedin-facebook: rshockey101 >> http//www.sipforum.org >> >> "Money is the answer, what is the question?" tm >> >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Tue Aug 20 09:52:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCEA21F862B for ; Tue, 20 Aug 2013 09:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[AWL=1.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ICBHwlQdv8K for ; Tue, 20 Aug 2013 09:52:19 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id B51B721F8607 for ; Tue, 20 Aug 2013 09:52:19 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id g10so624510pdj.16 for ; Tue, 20 Aug 2013 09:52:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JxBmomiKH1XE92KUrqAH/kzpR2z+I5NYySWimBKNOOw=; b=ReJPcobJziF1XVHUXa6QYIciU8+A4XpU1maQDUmqWRgZgP+M45upC+wypzFVJFGIzQ BT09wyYJkcFD4G5XK1tQTZOaU3Q2ORH31AhYE0KpYrYf9yXeaIXT+a6RNxvzgCJbg9CR fe/JX6gXITUkVSdrZKutEQat+xwEfWAPFbfV10loQnSSf1yy9MH3q916sDcCg4A48sHm 8k637SK7nT8zv6nkckAuSXpF9YIOzZjebaMykwJ+e602HNkBOaB8UXbEj4+PBRnN0jrz /ZNkklwbm8sARTwRPZEpO3+2ApLaGEIKXRX/AH+P//4D0xeSwDTY1c1EkSPLPrTsyX4s BZJQ== X-Gm-Message-State: ALoCoQmVNdXiIdgIMO1ls+dOdGQxHmF/3I7flkVRO/SvWO2aktpfIQ60PD9D8dNlsylblN0elh0i MIME-Version: 1.0 X-Received: by 10.68.223.225 with SMTP id qx1mr2992501pbc.157.1377017539257; Tue, 20 Aug 2013 09:52:19 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 20 Aug 2013 09:52:19 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <00ec01ce9dc4$375bff90$a613feb0$@shockey.us> References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> <521391BF.3030507@alum.mit.edu> <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> <00ec01ce9dc4$375bff90$a613feb0$@shockey.us> Date: Tue, 20 Aug 2013 12:52:19 -0400 Message-ID: From: Brian Rosen To: Richard Shockey Content-Type: multipart/alternative; boundary=047d7b16051546f88a04e463e1f1 Cc: "stir@ietf.org" , Hadriel Kaplan , Paul Kyzivat Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 16:52:23 -0000 --047d7b16051546f88a04e463e1f1 Content-Type: text/plain; charset=ISO-8859-1 Does the IETF have a way of supplying legislators with information? We probably would like to make them aware of our work. I know it was mentioned in FCC testimony, but do we have a more direct path? I'd be willing to work on this if there is a path. On Tue, Aug 20, 2013 at 12:42 PM, Richard Shockey wrote: > Exactly ... essentially useless. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: Tuesday, August 20, 2013 12:12 PM > To: Paul Kyzivat > Cc: stir@ietf.org > Subject: Re: [stir] Your DC newsletter of the day.... > > > It was discussed in the FTC subcommittee hearing, for which the video > recording is available here: > > http://www.commerce.senate.gov/public/index.cfm?p=Hearings&ContentRecord_id= > c1eec086-3512-4182-ae63-d60e68f4a532 > > There was an email thread on this in STIR list starting here: > http://www.ietf.org/mail-archive/web/stir/current/msg00762.html > > The two technologies discussed were Primus' TeleGuard, and Nomorobo. The > Primus one has been around for a while. > Unfortunately without STIR both of those "technologies" are easily > defeat-able, afaict. > > -hadriel > > > On Aug 20, 2013, at 11:56 AM, Paul Kyzivat wrote: > > > Richard, > > > > This letter says: "two robocall screening technologies were discussed in > some detail, one of which has been in operation for six years." > > > > What technologies were these? > > > > Thanks, > > Paul > > > > On 8/19/13 4:21 PM, Richard Shockey wrote: > >> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf > >> > >> FYI . > >> > >> Richard Shockey > >> Shockey Consulting > >> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 > >> 703.593.2683 > >> skype-linkedin-facebook: rshockey101 > >> http//www.sipforum.org > >> > >> "Money is the answer, what is the question?" tm > >> > >> > >> > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > >> > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7b16051546f88a04e463e1f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Does the IETF have a way of supplying legislators with inf= ormation? =A0We probably would like to make them aware of our work. =A0I kn= ow it was mentioned in FCC testimony, but do we have a more direct path? = =A0I'd be willing to work on this if there is a path.


On Tue, Aug 2= 0, 2013 at 12:42 PM, Richard Shockey <richard@shockey.us> w= rote:
Exactly ... essentially useless.

-----Original Message-----
From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] O= n Behalf Of
Hadriel Kaplan
Sent: Tuesday, August 20, 2013 12:12 PM
To: Paul Kyzivat
Cc: stir@ietf.org
Subject: Re: [stir] Your DC newsletter of the day....


It was discussed in the FTC subcommittee hearing, for which the video
recording is available here:
http://www.commerce= .senate.gov/public/index.cfm?p=3DHearings&ContentRecord_id=3D
c1eec086-3512-4182-ae63-d60e68f4a532

There was an email thread on this in STIR list starting here:
http://www.ietf.org/mail-archive/web/stir/current/msg007= 62.html

The two technologies discussed were Primus' TeleGuard, and Nomorobo. = =A0The
Primus one has been around for a while.
Unfortunately without STIR both of those "technologies" are easil= y
defeat-able, afaict.

-hadriel


On Aug 20, 2013, at 11:56 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Richard,
>
> This letter says: "two robocall screening technologies were discu= ssed in
some detail, one of which has been in operation for six years."
>
> What technologies were these?
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> On 8/19/13 4:21 PM, Richard Shockey wrote:
>> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCT= IA.pdf
>>
>> FYI .
>>
>> Richard Shockey
>> Shockey Consulting
>> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1
>> 703.593.2683 <mailto:richard(at)shockey.us>
>> skype-linkedin-facebook: rshockey101
>> http//www.si= pforum.org
>>
>> "Money is the answer, what is the question?" tm
>>
>>
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--047d7b16051546f88a04e463e1f1-- From hannes.tschofenig@gmx.net Tue Aug 20 10:23:17 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A5C21F9B10 for ; Tue, 20 Aug 2013 10:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waitR9RFHOM0 for ; Tue, 20 Aug 2013 10:23:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id ABC3A11E8124 for ; Tue, 20 Aug 2013 10:22:56 -0700 (PDT) Received: from [172.16.254.200] ([195.149.218.67]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MAkkB-1VLyuP3AXT-00Bs64 for ; Tue, 20 Aug 2013 19:22:51 +0200 Message-ID: <5213A5EA.3060700@gmx.net> Date: Tue, 20 Aug 2013 19:22:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> <521391BF.3030507@alum.mit.edu> <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> <00ec01ce9dc4$375bff90$a613feb0$@shockey.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mu6G3ao7YofKpF1xKTBivPdWIjzVU/hnTPJfMIH7LPWgK9PR3g4 mwlDJ+T40+sfrF6UXz67EebB1/t4Jw6SGqmr+G7i8VgOHIc19RqQaipvHuo7uWF7/iEmv6a I1PcoIlAm3+UpsAkDeIdqSQSXsyAldymbMeg4PtLg4/318nkcJm/8cGB9QLmseec7fvxmKn QO9XZ2oGHUx5yNMO9ri/g== Cc: "stir@ietf.org" , hannes.tschofenig@gmx.net, Hadriel Kaplan , Paul Kyzivat , Richard Shockey Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:23:17 -0000 The IAB is the best we have in the IETF context. The IAB maintains relationships with various organizations and also interacts with regulators in different areas. We obviously do the work with others, such as ISOC, since there are lots of regulators out there... What the best way is to share (or exchange) information needs to be determined on a case-by-case basis. I am happy to chat with you about what should/could be done. Ciao Hannes On 08/20/2013 06:52 PM, Brian Rosen wrote: > Does the IETF have a way of supplying legislators with information? We > probably would like to make them aware of our work. I know it was > mentioned in FCC testimony, but do we have a more direct path? I'd be > willing to work on this if there is a path. > > > On Tue, Aug 20, 2013 at 12:42 PM, Richard Shockey > wrote: > > Exactly ... essentially useless. > > -----Original Message----- > From: stir-bounces@ietf.org > [mailto:stir-bounces@ietf.org ] On > Behalf Of > Hadriel Kaplan > Sent: Tuesday, August 20, 2013 12:12 PM > To: Paul Kyzivat > Cc: stir@ietf.org > Subject: Re: [stir] Your DC newsletter of the day.... > > > It was discussed in the FTC subcommittee hearing, for which the video > recording is available here: > http://www.commerce.senate.gov/public/index.cfm?p=Hearings&ContentRecord_id= > c1eec086-3512-4182-ae63-d60e68f4a532 > c1eec086-3512-4182-ae63-d60e68f4a532> > > There was an email thread on this in STIR list starting here: > http://www.ietf.org/mail-archive/web/stir/current/msg00762.html > > The two technologies discussed were Primus' TeleGuard, and Nomorobo. > The > Primus one has been around for a while. > Unfortunately without STIR both of those "technologies" are easily > defeat-able, afaict. > > -hadriel > > > On Aug 20, 2013, at 11:56 AM, Paul Kyzivat > wrote: > > > Richard, > > > > This letter says: "two robocall screening technologies were > discussed in > some detail, one of which has been in operation for six years." > > > > What technologies were these? > > > > Thanks, > > Paul > > > > On 8/19/13 4:21 PM, Richard Shockey wrote: > >> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf > >> > >> FYI . > >> > >> Richard Shockey > >> Shockey Consulting > >> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 > >> 703.593.2683 (at)shockey.us > > >> skype-linkedin-facebook: rshockey101 > >> http//www.sipforum.org > >> > >> "Money is the answer, what is the question?" tm > >> > >> > >> > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > >> > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From richard@shockey.us Tue Aug 20 10:24:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7CA21F9B0D for ; Tue, 20 Aug 2013 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYdoeFbZnOkh for ; Tue, 20 Aug 2013 10:24:35 -0700 (PDT) Received: from oproxy12-pub.mail.unifiedlayer.com (oproxy12-pub.mail.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 7121421F9AFE for ; Tue, 20 Aug 2013 10:24:33 -0700 (PDT) Received: (qmail 8095 invoked by uid 0); 20 Aug 2013 17:24:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.mail.unifiedlayer.com with SMTP; 20 Aug 2013 17:24:07 -0000 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:Date:Subject:In-Reply-To:References:Cc:To:From; bh=WerEbBpHYH1oz+7XHBGa/bBzEsNSg+FKSFhD8E6xPz8=; b=Zoe34Z7+9yntbZ7YqJJTzzMikbOQ0TWpPC80qxWsazwkqzpuaSnWNeRmk++XivosLd1wI+JMDhEwfNhq2Jzwqefkq1Yt7h8TnrZ1QRwXCF7MyQtiDAP7u+LNTbIJemlu; Received: from [71.114.100.16] (port=52482 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBpf4-00072F-Dk; Tue, 20 Aug 2013 11:24:06 -0600 From: "Richard Shockey" To: "'Brian Rosen'" References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> <521391BF.3030507@alum.mit.edu> <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> <00ec01ce9dc4$375bff90$a613feb0$@shockey.us> In-Reply-To: Date: Tue, 20 Aug 2013 13:24:04 -0400 Message-ID: <00fe01ce9dca$12a91ab0$37fb5010$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FF_01CE9DA8.8B9A87F0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHf/Sb7v1qQL7dRTIR00ecfBw42tAEVZP+vAdE7YkoC0dV0TwIenM3fmTzbV2A= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org, 'Hadriel Kaplan' , 'Paul Kyzivat' Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:24:41 -0000 X-List-Received-Date: Tue, 20 Aug 2013 17:24:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FF_01CE9DA8.8B9A87F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That is ISOC's job. And what information would you supply? In what context? Representing who? And yes some of us have mentioned it to various board members etc in context with the PSTN transition but there are "issues" with that. Actually Congressional staff is rather approachable. Someone has to see all those lobbyists including the Legislative" Liaison" staff from the FCC and FTC. I wouldn't be concerned at this point. As I've said before STIR is only tangential to the larger problem. They do answer their phones. quaint idea. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, August 20, 2013 12:52 PM To: Richard Shockey Cc: stir@ietf.org; Hadriel Kaplan; Paul Kyzivat Subject: Re: [stir] Your DC newsletter of the day.... Does the IETF have a way of supplying legislators with information? We probably would like to make them aware of our work. I know it was mentioned in FCC testimony, but do we have a more direct path? I'd be willing to work on this if there is a path. On Tue, Aug 20, 2013 at 12:42 PM, Richard Shockey > wrote: Exactly ... essentially useless. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org ] On Behalf Of Hadriel Kaplan Sent: Tuesday, August 20, 2013 12:12 PM To: Paul Kyzivat Cc: stir@ietf.org Subject: Re: [stir] Your DC newsletter of the day.... It was discussed in the FTC subcommittee hearing, for which the video recording is available here: http://www.commerce.senate.gov/public/index.cfm?p=Hearings &ContentRecord_id= c1eec086-3512-4182-ae63-d60e68f4a532 There was an email thread on this in STIR list starting here: http://www.ietf.org/mail-archive/web/stir/current/msg00762.html The two technologies discussed were Primus' TeleGuard, and Nomorobo. The Primus one has been around for a while. Unfortunately without STIR both of those "technologies" are easily defeat-able, afaict. -hadriel On Aug 20, 2013, at 11:56 AM, Paul Kyzivat > wrote: > Richard, > > This letter says: "two robocall screening technologies were discussed in some detail, one of which has been in operation for six years." > > What technologies were these? > > Thanks, > Paul > > On 8/19/13 4:21 PM, Richard Shockey wrote: >> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf >> >> FYI . >> >> Richard Shockey >> Shockey Consulting >> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 >> 703.593.2683 (at)shockey.us > >> skype-linkedin-facebook: rshockey101 >> http//www.sipforum.org >> >> "Money is the answer, what is the question?" tm >> >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00FF_01CE9DA8.8B9A87F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That is ISOC’s job.  

 

And what information would you supply?  In what context? =  Representing who?

 

And yes some of us have mentioned it to various board members etc in = context with the PSTN transition but there are “issues” with = that.

 

Actually Congressional staff is rather approachable. Someone has to = see all those lobbyists including the Legislative” Liaison” = staff from the FCC and FTC.

 

I wouldn’t be concerned at this point.  As I’ve said = before STIR is only tangential to the larger problem. =

 

They do answer their phones… quaint idea. =

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Brian Rosen
Sent: Tuesday, August 20, 2013 12:52 = PM
To: Richard Shockey
Cc: stir@ietf.org; Hadriel = Kaplan; Paul Kyzivat
Subject: Re: [stir] Your DC newsletter of = the day....

 

Does = the IETF have a way of supplying legislators with information?  We = probably would like to make them aware of our work.  I know it was = mentioned in FCC testimony, but do we have a more direct path?  I'd = be willing to work on this if there is a = path.

 

On Tue, Aug 20, 2013 at 12:42 PM, Richard Shockey = <richard@shockey.us> = wrote:

Exactly = ... essentially useless.


-----Original Message-----
From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On = Behalf Of
Hadriel Kaplan
Sent: Tuesday, August 20, 2013 12:12 = PM
To: Paul Kyzivat
Cc: stir@ietf.org
Subject: Re: [stir] = Your DC newsletter of the day....


It was discussed in the FTC = subcommittee hearing, for which the video
recording is available = here:
http://www.commerce.senate.gov/public/index.cfm?p=3DHea= rings&ContentRecord_id=3D
c1eec086-3512-4182-ae63-d60e68f4a532=

There was an email thread on this in STIR list starting = here:
http://www.ietf.org/mail-archive/web/stir/current/msg00= 762.html

The two technologies discussed were Primus' = TeleGuard, and Nomorobo.  The
Primus one has been around for a = while.
Unfortunately without STIR both of those = "technologies" are easily
defeat-able, = afaict.

-hadriel


On Aug 20, 2013, at 11:56 AM, Paul = Kyzivat <pkyzivat@alum.mit.edu> = wrote:

> Richard,
>
> This letter says: "two = robocall screening technologies were discussed in
some detail, one of = which has been in operation for six years."
>
> What = technologies were these?
>
>       = Thanks,
>       Paul
>
> On 8/19/13 = 4:21 PM, Richard Shockey wrote:
>> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.= pdf
>>
>> FYI .
>>
>> Richard = Shockey
>> Shockey Consulting
>> Chairman of the Board = of Directors SIP Forum PSTN Mobile: +1
>> 703.593.2683 <mailto:richard(at)shockey.us>
>> = skype-linkedin-facebook: rshockey101
>> http//www.sipforum.org
>>
>> = "Money is the answer, what is the question?" = tm
>>
>>
>>
>> = _______________________________________________
>> stir mailing = list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>&= gt;
>
> = _______________________________________________
> stir mailing = list
> stir@ietf.org
> = https://www.ietf.org/mailman/listinfo/stir

_= ______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_= ______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 

------=_NextPart_000_00FF_01CE9DA8.8B9A87F0-- From kent@bbn.com Tue Aug 20 10:39:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C7911E80E4 for ; Tue, 20 Aug 2013 10:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmIZZvEncDPE for ; Tue, 20 Aug 2013 10:38:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 54B6C21F9C72 for ; Tue, 20 Aug 2013 10:38:55 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49732) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBptN-000FxF-Kw; Tue, 20 Aug 2013 13:38:53 -0400 Message-ID: <5213A9AD.3070900@bbn.com> Date: Tue, 20 Aug 2013 13:38:53 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henning Schulzrinne References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <52138A07.3080800@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org List" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Brian Rosen Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:39:02 -0000 Henning, I think the problem will be more subtle than just the Nigerian example, based on some experience in the PKI arena, but ... Steve From Henning.Schulzrinne@fcc.gov Tue Aug 20 10:41:46 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793DF21F9A1B for ; Tue, 20 Aug 2013 10:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRa6HQ4q0K8E for ; Tue, 20 Aug 2013 10:41:42 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 3874621F8F4D for ; Tue, 20 Aug 2013 10:41:42 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hannes Tschofenig' Thread-Topic: [stir] Your DC newsletter of the day.... Thread-Index: Ac6dGatLd12TFfewT0GTcH+cFoT8MwAxbuaAAACKbwAAAQsugAAAWuWAAAEQ1wAAB+fecA== Date: Tue, 20 Aug 2013 17:41:40 +0000 References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> <521391BF.3030507@alum.mit.edu> <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> <00ec01ce9dc4$375bff90$a613feb0$@shockey.us> <5213A5EA.3060700@gmx.net> In-Reply-To: <5213A5EA.3060700@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:41:46 -0000 In general and speaking of the US rather than internationally, both regulat= ors and congressional staff appreciate receiving fact-based materials on to= pics of interest. For Congress, it's informal - a letter from an organizati= on will do. For the FCC, formality matters mostly during rule makings. Havi= ng something citable (and credible and not too long) is very helpful in bot= h cases. In this particular case, I suspect the information deficit is larg= er on the congressional side. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Han= nes Tschofenig Sent: Tuesday, August 20, 2013 1:23 PM To: Brian Rosen Cc: stir@ietf.org; hannes.tschofenig@gmx.net; Hadriel Kaplan; Paul Kyzivat;= Richard Shockey Subject: Re: [stir] Your DC newsletter of the day.... The IAB is the best we have in the IETF context. The IAB maintains relation= ships with various organizations and also interacts with regulators in diff= erent areas. We obviously do the work with others, such as ISOC, since ther= e are lots of regulators out there... What the best way is to share (or exchange) information needs to be determi= ned on a case-by-case basis. I am happy to chat with you about what should/= could be done. Ciao Hannes On 08/20/2013 06:52 PM, Brian Rosen wrote: > Does the IETF have a way of supplying legislators with information? =20 > We probably would like to make them aware of our work. I know it was=20 > mentioned in FCC testimony, but do we have a more direct path? I'd be=20 > willing to work on this if there is a path. > > > On Tue, Aug 20, 2013 at 12:42 PM, Richard Shockey > wrote: > > Exactly ... essentially useless. > > -----Original Message----- > From: stir-bounces@ietf.org > [mailto:stir-bounces@ietf.org ] On > Behalf Of > Hadriel Kaplan > Sent: Tuesday, August 20, 2013 12:12 PM > To: Paul Kyzivat > Cc: stir@ietf.org > Subject: Re: [stir] Your DC newsletter of the day.... > > > It was discussed in the FTC subcommittee hearing, for which the video > recording is available here: > http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentR= ecord_id=3D > c1eec086-3512-4182-ae63-d60e68f4a532 > c1eec086-3512-4182-ae63-d60e68f4a532> > > There was an email thread on this in STIR list starting here: > http://www.ietf.org/mail-archive/web/stir/current/msg00762.html > > The two technologies discussed were Primus' TeleGuard, and Nomorobo. > The > Primus one has been around for a while. > Unfortunately without STIR both of those "technologies" are easily > defeat-able, afaict. > > -hadriel > > > On Aug 20, 2013, at 11:56 AM, Paul Kyzivat > wrote: > > > Richard, > > > > This letter says: "two robocall screening technologies were > discussed in > some detail, one of which has been in operation for six years." > > > > What technologies were these? > > > > Thanks, > > Paul > > > > On 8/19/13 4:21 PM, Richard Shockey wrote: > >> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf > >> > >> FYI . > >> > >> Richard Shockey > >> Shockey Consulting > >> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 > >> 703.593.2683 (at)shockey.us > > >> skype-linkedin-facebook: rshockey101 > >> http//www.sipforum.org From michael.hammer@yaanatech.com Tue Aug 20 10:44:21 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7AC11E8142 for ; Tue, 20 Aug 2013 10:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=1.218, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxEgkkssOgY6 for ; Tue, 20 Aug 2013 10:44:17 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id C28BB11E823A for ; Tue, 20 Aug 2013 10:44:17 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 20 Aug 2013 10:44:17 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "hannes.tschofenig@gmx.net" Thread-Topic: [stir] Your DC newsletter of the day.... Thread-Index: Ac6dGatLd12TFfewT0GTcH+cFoT8MwA3uDqAAACKbgAAAQsugAAAWuWAAAEQ2AAAAKhiAAAOmsRQ Date: Tue, 20 Aug 2013 17:44:16 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2B062@EX2K10MB1.corp.yaanatech.com> References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> <521391BF.3030507@alum.mit.edu> <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> <00ec01ce9dc4$375bff90$a613feb0$@shockey.us> <5213A5EA.3060700@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.131] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01C7_01CE9DAB.5C5E3790" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:44:21 -0000 ------=_NextPart_000_01C7_01CE9DAB.5C5E3790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Oh, but be careful what you wish for. You might just get a 1,000 page law that no one understands. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Tuesday, August 20, 2013 1:42 PM To: 'Hannes Tschofenig' Cc: stir@ietf.org Subject: Re: [stir] Your DC newsletter of the day.... In general and speaking of the US rather than internationally, both regulators and congressional staff appreciate receiving fact-based materials on topics of interest. For Congress, it's informal - a letter from an organization will do. For the FCC, formality matters mostly during rule makings. Having something citable (and credible and not too long) is very helpful in both cases. In this particular case, I suspect the information deficit is larger on the congressional side. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, August 20, 2013 1:23 PM To: Brian Rosen Cc: stir@ietf.org; hannes.tschofenig@gmx.net; Hadriel Kaplan; Paul Kyzivat; Richard Shockey Subject: Re: [stir] Your DC newsletter of the day.... The IAB is the best we have in the IETF context. The IAB maintains relationships with various organizations and also interacts with regulators in different areas. We obviously do the work with others, such as ISOC, since there are lots of regulators out there... What the best way is to share (or exchange) information needs to be determined on a case-by-case basis. I am happy to chat with you about what should/could be done. Ciao Hannes On 08/20/2013 06:52 PM, Brian Rosen wrote: > Does the IETF have a way of supplying legislators with information? > We probably would like to make them aware of our work. I know it was > mentioned in FCC testimony, but do we have a more direct path? I'd be > willing to work on this if there is a path. > > > On Tue, Aug 20, 2013 at 12:42 PM, Richard Shockey > wrote: > > Exactly ... essentially useless. > > -----Original Message----- > From: stir-bounces@ietf.org > [mailto:stir-bounces@ietf.org ] On > Behalf Of > Hadriel Kaplan > Sent: Tuesday, August 20, 2013 12:12 PM > To: Paul Kyzivat > Cc: stir@ietf.org > Subject: Re: [stir] Your DC newsletter of the day.... > > > It was discussed in the FTC subcommittee hearing, for which the video > recording is available here: > http://www.commerce.senate.gov/public/index.cfm?p=Hearings&ContentRecord_id= > c1eec086-3512-4182-ae63-d60e68f4a532 > c1eec086-3512-4182-ae63-d60e68f4a532> > > There was an email thread on this in STIR list starting here: > http://www.ietf.org/mail-archive/web/stir/current/msg00762.html > > The two technologies discussed were Primus' TeleGuard, and Nomorobo. > The > Primus one has been around for a while. > Unfortunately without STIR both of those "technologies" are easily > defeat-able, afaict. > > -hadriel > > > On Aug 20, 2013, at 11:56 AM, Paul Kyzivat > wrote: > > > Richard, > > > > This letter says: "two robocall screening technologies were > discussed in > some detail, one of which has been in operation for six years." > > > > What technologies were these? > > > > Thanks, > > Paul > > > > On 8/19/13 4:21 PM, Richard Shockey wrote: > >> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf > >> > >> FYI . > >> > >> Richard Shockey > >> Shockey Consulting > >> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 > >> 703.593.2683 (at)shockey.us > > >> skype-linkedin-facebook: rshockey101 > >> http//www.sipforum.org _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_01C7_01CE9DAB.5C5E3790 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgy MDE3NDQxNVowIwYJKoZIhvcNAQkEMRYEFHlb6fJ8Tl7ArZXTuGCTyFMObYavMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAbSefSB2NofGENMHLmEbQPuAaGwTNg3VM/9vqAKfx +exo1a5EtmYS63uZvQfBdYLV7cX9bcADVsduLKZozQvx4s1NJM53qDztwjRf9h2tTzxVwADvH4nl 2Eahte5BgjbXj/WzMbDNEWjdxrhoQJsXSMIOTtzFg6UVZP79VnhrTIUHnFsMkpI8b9EXf+jGzRw/ GsYwroOOPtfq5vUSaiC+bxTp3SbUo6O3luMQ/VfNJyXx+AsrqvQxZ8BiIfqESSG6uNc1Nn/O5z3R HndhDiETiLKC1ORPdyxveeQ9uS85+lIAWYzuswL51N5htCpw3pNiXaoAUgHS7m/mhv4ZBzWSUgAA AAAAAA== ------=_NextPart_000_01C7_01CE9DAB.5C5E3790-- From kent@bbn.com Tue Aug 20 10:44:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D5921F9AEB for ; Tue, 20 Aug 2013 10:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEJ08kBHlzGc for ; Tue, 20 Aug 2013 10:44:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5EECB11E813D for ; Tue, 20 Aug 2013 10:44:44 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49743) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBpz0-000G4B-Bq; Tue, 20 Aug 2013 13:44:42 -0400 Message-ID: <5213AB0A.3090603@bbn.com> Date: Tue, 20 Aug 2013 13:44:42 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:44:50 -0000 Brian, > There isn't a database that will supply a unique identifier for all > contexts. OTOH, if you are a US resident, we could get a pretty good > score comparing your name to your phone number, and if we had an > address, we probably can get a pretty high score. That would provide > a pretty meaningful assurance on the name attached to a phone call if > we could manage to get the mechanics worked out. These databases > exist in most developed countries. Score? I hope we're not planning to send the score to the callee, as that will probably confuse them. If the score is for internal use by a service provider, then there is the risk that different providers will have different thresholds, which leads to a different sort of confusion. > This is much better than we have today, because in most cases there is > no attempt to validate the name when a service provider gets a new > customer. > > If we could use these databases to score the name associated with the > number, especially if the originating service provider obtained and > supplied other information to the validation service (at the > initiation of service, and possibly periodically after), then the > validation service could provide a pretty decent score at the > termination end. Are we talking about the VoIP version of "Name that Tune": "it's got great lyrics and a good beat, so I give it a 7" Steve From michael.hammer@yaanatech.com Tue Aug 20 10:50:22 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AAF11E8202 for ; Tue, 20 Aug 2013 10:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLL2xidV+7Ye for ; Tue, 20 Aug 2013 10:50:18 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 66C0A11E8119 for ; Tue, 20 Aug 2013 10:50:13 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 20 Aug 2013 10:50:11 -0700 From: Michael Hammer To: "kent@bbn.com" , "br@brianrosen.net" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAAwhwCAAGoAgIAAIfKAgAT4oQCAAAiNAIAACBAAgAAIEoCAAX8dAP//i6xw Date: Tue, 20 Aug 2013 17:50:10 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2B0BF@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> In-Reply-To: <5213AB0A.3090603@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.131] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01E8_01CE9DAC.2F819400" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:50:23 -0000 ------=_NextPart_000_01E8_01CE9DAC.2F819400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit LOL, different type of score I think. I think he is aiming for something that is 1-9's or less. (And yes, I know this is a different sort of reliability to measure.) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, August 20, 2013 1:45 PM To: Brian Rosen Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) Brian, > There isn't a database that will supply a unique identifier for all > contexts. OTOH, if you are a US resident, we could get a pretty good > score comparing your name to your phone number, and if we had an > address, we probably can get a pretty high score. That would provide > a pretty meaningful assurance on the name attached to a phone call if > we could manage to get the mechanics worked out. These databases > exist in most developed countries. Score? I hope we're not planning to send the score to the callee, as that will probably confuse them. If the score is for internal use by a service provider, then there is the risk that different providers will have different thresholds, which leads to a different sort of confusion. > This is much better than we have today, because in most cases there is > no attempt to validate the name when a service provider gets a new > customer. > > If we could use these databases to score the name associated with the > number, especially if the originating service provider obtained and > supplied other information to the validation service (at the > initiation of service, and possibly periodically after), then the > validation service could provide a pretty decent score at the > termination end. Are we talking about the VoIP version of "Name that Tune": "it's got great lyrics and a good beat, so I give it a 7" Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_01E8_01CE9DAC.2F819400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgy MDE3NTAwOVowIwYJKoZIhvcNAQkEMRYEFE5t61G6YsV6LuTCYep9/FGyZmErMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAc6fedWmD8+BbMfNkmUj1oU9b+w/Cc15E44PgKPVq Tr5ewmyX/U9Q+um3qHow4Dar5khnVuEh3JmvS/6VvpZfLM+dJ+caGkrsTg61Sp9b124/F2t4/h0H nchku6X/hVMB3rrhqYLm5oCZz3DnpRQhq8QEIQCn5XhFGBuJ2pLXU5jF5nX4u7OAxSHWI+21CgC4 WarDnbyBFSDyKD+8qxDq21gAl55MhT//AV/sficnoWqW8IOLtcC7ZNlQ77qh25h6udbmXO/jlmSM mIwZxBIUzLLh6cc3lmMeDKoXpG8hVIu3QCd3zMHrLIFXxmgTyZf8zFcbWsRByHUbKAK3ne7iewAA AAAAAA== ------=_NextPart_000_01E8_01CE9DAC.2F819400-- From stephen.farrell@cs.tcd.ie Tue Aug 20 10:54:39 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B9121F9CC6 for ; Tue, 20 Aug 2013 10:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzlrBtJy6rZr for ; Tue, 20 Aug 2013 10:54:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B9B5E21F9C86 for ; Tue, 20 Aug 2013 10:54:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AA8C5BE4D; Tue, 20 Aug 2013 18:54:27 +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 2GTmAM-W8CEq; Tue, 20 Aug 2013 18:54:26 +0100 (IST) Received: from [10.228.74.176] (unknown [88.128.80.13]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4E8EEBE6F; Tue, 20 Aug 2013 18:54:26 +0100 (IST) References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <52138A07.3080800@bbn.com> <5213A9AD.307 0900@bbn.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5213A9AD.3070900@bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Stephen Farrell Date: Tue, 20 Aug 2013 19:54:22 +0200 To: Stephen Kent Cc: "stir@ietf.org List" , Brian Rosen , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:54:39 -0000 On 20 Aug 2013, at 19:38, Stephen Kent wrote: > Henning, >=20 > I think the problem will be more subtle than just the Nigerian example, ba= sed on some experience in the PKI arena, but ... Without having really caught up with thread, I'm pretty sure I agree with St= eve - adding another dimension of naming to STIR seems like a bad plan fraug= ht with complexity, S >=20 > Steve >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Tue Aug 20 10:58:26 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064C311E812F for ; Tue, 20 Aug 2013 10:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=1.290, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ6PuYelM5mw for ; Tue, 20 Aug 2013 10:57:53 -0700 (PDT) Received: from oproxy14-pub.mail.unifiedlayer.com (oproxy14-pub.mail.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 5CDE711E8114 for ; Tue, 20 Aug 2013 10:57:09 -0700 (PDT) Received: (qmail 29061 invoked by uid 0); 20 Aug 2013 17:56:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 20 Aug 2013 17:56:34 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=LSYVsAA85WzKISQ/uIk4+L07g9WPLxDvD1bvhAmpXdk=; b=dqcD4NtxQs3q62BsCdTdeOo5brKkHXNQXiGlTuvp/f6rVQ83TqqeCv3WVaKmOA9yAnkKglhqx97PIzrddoVDn05/vp5SoM0jsremSjeoakAhzaN6FAGxQ8PyzmwFJn/v; Received: from [71.114.100.16] (port=53549 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBqAT-0005Ac-4r; Tue, 20 Aug 2013 11:56:33 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> <521391BF.3030507@alum.mit.edu> <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> <00ec01ce9dc4$375bff90$a613feb0$@shockey.us> <5213A5EA.3060700@gmx.net> <00C069FD01E0324C9FFCADF539701DB3BBC2B062@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2B062@EX2K10MB1.corp.yaanatech.com> Date: Tue, 20 Aug 2013 13:56:31 -0400 Message-ID: <011101ce9dce$9afda120$d0f8e360$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHf/Sb7v1qQL7dRTIR00ecfBw42tAEVZP+vAdE7YkoC0dV0TwIenM3fAeNVaRIClr6fNAJnatANmQXdAqA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:58:26 -0000 Of course for maximum "impact" you can try and get a mention about STIR in POLITICO Playbook especially before the all essential Birth week and Birthday section. Required reading in "This Town" http://www.politico.com/playbook/ http://www.amazon.com/This-Town-Parties-Funeral-Plus-Americas/dp/0399161309# -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, August 20, 2013 1:44 PM To: Henning.Schulzrinne@fcc.gov; hannes.tschofenig@gmx.net Cc: stir@ietf.org Subject: Re: [stir] Your DC newsletter of the day.... Oh, but be careful what you wish for. You might just get a 1,000 page law that no one understands. [RS> ] Exactly like the Truth in Caller ID Act. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Tuesday, August 20, 2013 1:42 PM To: 'Hannes Tschofenig' Cc: stir@ietf.org Subject: Re: [stir] Your DC newsletter of the day.... In general and speaking of the US rather than internationally, both regulators and congressional staff appreciate receiving fact-based materials on topics of interest. For Congress, it's informal - a letter from an organization will do. For the FCC, formality matters mostly during rule makings. Having something citable (and credible and not too long) is very helpful in both cases. In this particular case, I suspect the information deficit is larger on the congressional side. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, August 20, 2013 1:23 PM To: Brian Rosen Cc: stir@ietf.org; hannes.tschofenig@gmx.net; Hadriel Kaplan; Paul Kyzivat; Richard Shockey Subject: Re: [stir] Your DC newsletter of the day.... The IAB is the best we have in the IETF context. The IAB maintains relationships with various organizations and also interacts with regulators in different areas. We obviously do the work with others, such as ISOC, since there are lots of regulators out there... What the best way is to share (or exchange) information needs to be determined on a case-by-case basis. I am happy to chat with you about what should/could be done. Ciao Hannes On 08/20/2013 06:52 PM, Brian Rosen wrote: > Does the IETF have a way of supplying legislators with information? > We probably would like to make them aware of our work. I know it was > mentioned in FCC testimony, but do we have a more direct path? I'd be > willing to work on this if there is a path. > > > On Tue, Aug 20, 2013 at 12:42 PM, Richard Shockey > wrote: > > Exactly ... essentially useless. > > -----Original Message----- > From: stir-bounces@ietf.org > [mailto:stir-bounces@ietf.org ] On > Behalf Of > Hadriel Kaplan > Sent: Tuesday, August 20, 2013 12:12 PM > To: Paul Kyzivat > Cc: stir@ietf.org > Subject: Re: [stir] Your DC newsletter of the day.... > > > It was discussed in the FTC subcommittee hearing, for which the video > recording is available here: > http://www.commerce.senate.gov/public/index.cfm?p=Hearings&ContentRecord_id= > c1eec086-3512-4182-ae63-d60e68f4a532 > c1eec086-3512-4182-ae63-d60e68f4a532> > > There was an email thread on this in STIR list starting here: > http://www.ietf.org/mail-archive/web/stir/current/msg00762.html > > The two technologies discussed were Primus' TeleGuard, and Nomorobo. > The > Primus one has been around for a while. > Unfortunately without STIR both of those "technologies" are easily > defeat-able, afaict. > > -hadriel > > > On Aug 20, 2013, at 11:56 AM, Paul Kyzivat > wrote: > > > Richard, > > > > This letter says: "two robocall screening technologies were > discussed in > some detail, one of which has been in operation for six years." > > > > What technologies were these? > > > > Thanks, > > Paul > > > > On 8/19/13 4:21 PM, Richard Shockey wrote: > >> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf > >> > >> FYI . > >> > >> Richard Shockey > >> Shockey Consulting > >> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 > >> 703.593.2683 (at)shockey.us > > >> skype-linkedin-facebook: rshockey101 > >> http//www.sipforum.org _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Tue Aug 20 11:01:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C30A11E8117 for ; Tue, 20 Aug 2013 11:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iEAFe0-GOeq for ; Tue, 20 Aug 2013 11:01:27 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4E711E8113 for ; Tue, 20 Aug 2013 11:01:25 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so694774pbb.13 for ; Tue, 20 Aug 2013 11:01:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b5m+WNMNPFowccCPFnHCcKO6KelmzoIr9GuauJjujWg=; b=L2QsqVJtEHutwdKfh2LTLywOKpuf8n+83hZM/ALJEI5uB1klhmmqbC/u6YQrk4Qd0y hopc3Ecij2xIREAOCtaJLqJJsVOriLpzbeznniS0+B1zheyRImOEwsfSKUOFEqnG8k7A Swsw27H/ju4Eb4xDZiURYChn8TH0sHobvJRuC+l1FmNoec3Bw/ZjMJzAiK9GgFJ+K1Ni 72KI1YT+imMm9xc5CjkL4DxFKp7EMGFs4Ahlduq8km7s9f7mRJrFobBDG91LJ9PEADrK PYJDmSSa6dE82OUmaumWYFcdv9UDl0aG1w1wptSJhE7UPIQkXa/QTaT7vPQ7TAh+ynYX Z+dw== X-Gm-Message-State: ALoCoQlfK9Dz/Pyf5UgQx5BNzWhceaffDqNLd1Z3slqmyMDs+9XCQkQWdtCQDZAe6YIEbpgP5fx5 MIME-Version: 1.0 X-Received: by 10.66.118.129 with SMTP id km1mr5125542pab.127.1377021685020; Tue, 20 Aug 2013 11:01:25 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 20 Aug 2013 11:01:24 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <5213AB0A.3090603@bbn.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> Date: Tue, 20 Aug 2013 14:01:24 -0400 Message-ID: From: Brian Rosen To: Stephen Kent Content-Type: multipart/alternative; boundary=e89a8ffbab6b625a0e04e464d8be Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:01:40 -0000 --e89a8ffbab6b625a0e04e464d8be Content-Type: text/plain; charset=ISO-8859-1 The score could be used by a smart device to display something appropriate. A service provider could establish thresholds for dumb devices. Lots of existing systems use scores for similar problems. The data is not definitive, so instead of go/no go, you get a score. There are lots of fields in these databases. The more input you provide, the more accurate the result. The mechanics of the databases and scoring, and even using scores, is well established data science. The only new stuff here is the mechanics of carrying it. Brian On Tue, Aug 20, 2013 at 1:44 PM, Stephen Kent wrote: > Brian, > > > There isn't a database that will supply a unique identifier for all >> contexts. OTOH, if you are a US resident, we could get a pretty good score >> comparing your name to your phone number, and if we had an address, we >> probably can get a pretty high score. That would provide a pretty >> meaningful assurance on the name attached to a phone call if we could >> manage to get the mechanics worked out. These databases exist in most >> developed countries. >> > Score? I hope we're not planning to send the score to the callee, as that > will probably > confuse them. If the score is for internal use by a service provider, then > there is the > risk that different providers will have different thresholds, which leads > to a different sort of confusion. > > This is much better than we have today, because in most cases there is no >> attempt to validate the name when a service provider gets a new customer. >> >> If we could use these databases to score the name associated with the >> number, especially if the originating service provider obtained and >> supplied other information to the validation service (at the initiation of >> service, and possibly periodically after), then the validation service >> could provide a pretty decent score at the termination end. >> > Are we talking about the VoIP version of "Name that Tune": > "it's got great lyrics and a good beat, so I give it a 7" > > Steve > --e89a8ffbab6b625a0e04e464d8be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The score could be used by a smart device to display somet= hing appropriate. =A0A service provider could establish thresholds for dumb= devices.

Lots of existing systems use scores for simila= r problems. =A0The data is not definitive, so instead of go/no go, you get = a score. =A0There are lots of fields in these databases. =A0The more input = you provide, the more accurate the result. =A0

The mechanics of the databases and scoring, and even us= ing scores, is well established data science. =A0The only new stuff here is= the mechanics of carrying it.

Brian


On Tue, Aug 2= 0, 2013 at 1:44 PM, Stephen Kent <kent@bbn.com> wrote:
Brian,


There isn't a database that will supply a unique identifier for all con= texts. =A0OTOH, if you are a US resident, we could get a pretty good score = comparing your name to your phone number, and if we had an address, we prob= ably can get a pretty high score. =A0That would provide a pretty meaningful= assurance on the name attached to a phone call if we could manage to get t= he mechanics worked out. =A0These databases exist in most developed countri= es.
Score? I hope we're not planning to send the score to the callee, as th= at will probably
confuse them. If the score is for internal use by a service provider, then = there is the
risk that different providers will have different thresholds, which leads t= o a different sort of confusion.

This is much better than we have today, because in most cases there is no a= ttempt to validate the name when a service provider gets a new customer.
If we could use these databases to score the name associated with the numbe= r, especially if the originating service provider obtained and supplied oth= er information to the validation service (at the initiation of service, and= possibly periodically after), then the validation service could provide a = pretty decent score at the termination end.
Are we talking about the VoIP version of "Name that Tune":
=A0 =A0 "it's got great lyrics and a good beat, so I give it a 7&q= uot;

Steve

--e89a8ffbab6b625a0e04e464d8be-- From michael.hammer@yaanatech.com Tue Aug 20 11:20:56 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B5111E8119 for ; Tue, 20 Aug 2013 11:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epcOUQUbqbOX for ; Tue, 20 Aug 2013 11:20:51 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 307DA11E811E for ; Tue, 20 Aug 2013 11:20:51 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 20 Aug 2013 11:20:50 -0700 From: Michael Hammer To: "br@brianrosen.net" , "kent@bbn.com" Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: AQHOmPKk5o9ZylHJ0k6D3ap6F4W3oZmVOuYAgAA2EwCAAA1WAIAAByIAgAAESwCAAZf6AIAAbr2AgAAwhwCAAGoAgIAAIfKAgAT4oQCAAAiNAIAACBAAgAAIEoCAAX8dAIAABKsA//+PUPA= Date: Tue, 20 Aug 2013 18:20:50 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.131] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0235_01CE9DB0.77D0A350" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:20:56 -0000 ------=_NextPart_000_0235_01CE9DB0.77D0A350 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0236_01CE9DB0.77D0A350" ------=_NextPart_001_0236_01CE9DB0.77D0A350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Great for nerds. But, I think if you tell the average person, that the call is 60% assured of coming from First National Bank, what does that mean? It means the telephone network is broken, since it doesn't know what it is doing. Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, August 20, 2013 2:01 PM To: Stephen Kent Cc: stir@ietf.org List Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) The score could be used by a smart device to display something appropriate. A service provider could establish thresholds for dumb devices. Lots of existing systems use scores for similar problems. The data is not definitive, so instead of go/no go, you get a score. There are lots of fields in these databases. The more input you provide, the more accurate the result. The mechanics of the databases and scoring, and even using scores, is well established data science. The only new stuff here is the mechanics of carrying it. Brian On Tue, Aug 20, 2013 at 1:44 PM, Stephen Kent wrote: Brian, There isn't a database that will supply a unique identifier for all contexts. OTOH, if you are a US resident, we could get a pretty good score comparing your name to your phone number, and if we had an address, we probably can get a pretty high score. That would provide a pretty meaningful assurance on the name attached to a phone call if we could manage to get the mechanics worked out. These databases exist in most developed countries. Score? I hope we're not planning to send the score to the callee, as that will probably confuse them. If the score is for internal use by a service provider, then there is the risk that different providers will have different thresholds, which leads to a different sort of confusion. This is much better than we have today, because in most cases there is no attempt to validate the name when a service provider gets a new customer. If we could use these databases to score the name associated with the number, especially if the originating service provider obtained and supplied other information to the validation service (at the initiation of service, and possibly periodically after), then the validation service could provide a pretty decent score at the termination end. Are we talking about the VoIP version of "Name that Tune": "it's got great lyrics and a good beat, so I give it a 7" Steve ------=_NextPart_001_0236_01CE9DB0.77D0A350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Great for nerds. 

 

But, I think if you tell the average person,

that the call is 60% assured of coming from First National Bank, =

what does that mean?

 

It means the telephone network is broken,

since it doesn’t know what it is doing.

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Brian Rosen
Sent: Tuesday, August 20, 2013 2:01 = PM
To: Stephen Kent
Cc: stir@ietf.org = List
Subject: Re: [stir] Early Homework (was Re: Moving from = BOF to Charter)

 

The = score could be used by a smart device to display something appropriate. =  A service provider could establish thresholds for dumb = devices.

 

Lots of existing systems use scores for similar = problems.  The data is not definitive, so instead of go/no go, you = get a score.  There are lots of fields in these databases. =  The more input you provide, the more accurate the result. =  

 

The mechanics of the databases and scoring, and even = using scores, is well established data science.  The only new stuff = here is the mechanics of carrying it.

 

Brian

 

On Tue, Aug 20, 2013 at 1:44 PM, Stephen Kent <kent@bbn.com> = wrote:

Brian,

 

There isn't a database that will supply a unique = identifier for all contexts.  OTOH, if you are a US resident, we = could get a pretty good score comparing your name to your phone number, = and if we had an address, we probably can get a pretty high score. =  That would provide a pretty meaningful assurance on the name = attached to a phone call if we could manage to get the mechanics worked = out.  These databases exist in most developed = countries.

Score? = I hope we're not planning to send the score to the callee, as that will = probably
confuse them. If the score is for internal use by a service = provider, then there is the
risk that different providers will have = different thresholds, which leads to a different sort of = confusion.

 

This is much = better than we have today, because in most cases there is no attempt to = validate the name when a service provider gets a new customer.

If = we could use these databases to score the name associated with the = number, especially if the originating service provider obtained and = supplied other information to the validation service (at the initiation = of service, and possibly periodically after), then the validation = service could provide a pretty decent score at the termination = end.

Are we = talking about the VoIP version of "Name that Tune":
  =   "it's got great lyrics and a good beat, so I give it a = 7"

Steve

 

------=_NextPart_001_0236_01CE9DB0.77D0A350-- ------=_NextPart_000_0235_01CE9DB0.77D0A350 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgy MDE4MjA0OVowIwYJKoZIhvcNAQkEMRYEFEUNbs8AduqFNV85+hQMgnPRp3uPMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAD6TN/C8mVTg8MHRp+V5VwxEWYwSAG64qL5x6IOHw LLlFE98FgTxxp3gzyhLuxlH5zH9ia+njHWNw+hQc4FoCkPHn4rqHAP+fGtmjXHhf/HcUYlplxRrE UirgLyOpWSTOhVbHb/aocgTntjwt7PTMajvs6QJP0bPLuK8NxRu+iCVl6a5YLE7jnOsNnnjwA0iD gmB3sNAvOQPUi23zEkU65Gx1LJOHb1VskQRsOKUfFzinvi04ckha/nTGXSxxlzne5PGhEg5S3YWg QGWuo3cMfGKYwpM8E97InTXqIh8RrnFAFVw9Et3wKXTF7RswbHZkoRj0M323s9ZnOtkUMEO3XwAA AAAAAA== ------=_NextPart_000_0235_01CE9DB0.77D0A350-- From pkyzivat@alum.mit.edu Tue Aug 20 11:23:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D44111E8124 for ; Tue, 20 Aug 2013 11:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=1.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkZ8vQSnuqOK for ; Tue, 20 Aug 2013 11:23:07 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 08D7111E811E for ; Tue, 20 Aug 2013 11:23:06 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id EznN1m0010mv7h0546P0rD; Tue, 20 Aug 2013 18:23:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id F6P01m00T3ZTu2S3X6P0Re; Tue, 20 Aug 2013 18:23:00 +0000 Message-ID: <5213B403.3000603@alum.mit.edu> Date: Tue, 20 Aug 2013 14:22:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <019201ce9d19$b5dbb0a0$219311e0$@shockey.us> <521391BF.3030507@alum.mit.edu> <88A1FB9C-DE2A-48BB-8A8B-59FCEA416DE2@oracle.com> <00ec01ce9dc4$375bff90$a613feb0$@shockey.us> <5213A5EA.3060700@gmx.net> <00C069FD01E0324C9FFCADF539701DB3BBC2B062@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2B062@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377022980; bh=UYC0QkLOpXx4XXj6kolK22AOqR7FtSK818Ai8VisRpM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=n08fhcrJai+bg4Rm/mccjp5UCuwOpAGjZosJCwqiC6RZTDbrzUtC4bGP32O9utIJS MbF9asMY8MvtBbT/Q1c3RwI82V5n/62bYHdETgaLuzOPeH0pIf3/A7Ni/tHAmDoYBc b7mrqrKE1RM9gAV4JETJsoz0lcxYGx+HYyvf4BTbAIhQIzptMqzbH3MZEWrroH8TT7 jmKsQ/BijygTh02gqtIXt2UuzcDfV/udxzspryCdWkN7IdpuSjkKXKp6zHI0uxtnlF 2SsEA46I3Ly+hOl3AGG0DhTUaWcoirDUPznAC6hgJABOVqQmFrCoyNtFHIWEexaxP7 ZRV4Nb6LfNSEQ== Subject: Re: [stir] Your DC newsletter of the day.... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:23:11 -0000 On 8/20/13 1:44 PM, Michael Hammer wrote: > Oh, but be careful what you wish for. > You might just get a 1,000 page law that no one understands. The people who actually write it will understand it. We just won't know who they are. Thanks, Paul > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Tuesday, August 20, 2013 1:42 PM > To: 'Hannes Tschofenig' > Cc: stir@ietf.org > Subject: Re: [stir] Your DC newsletter of the day.... > > In general and speaking of the US rather than internationally, both > regulators and congressional staff appreciate receiving fact-based materials > on topics of interest. For Congress, it's informal - a letter from an > organization will do. For the FCC, formality matters mostly during rule > makings. Having something citable (and credible and not too long) is very > helpful in both cases. In this particular case, I suspect the information > deficit is larger on the congressional side. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, August 20, 2013 1:23 PM > To: Brian Rosen > Cc: stir@ietf.org; hannes.tschofenig@gmx.net; Hadriel Kaplan; Paul Kyzivat; > Richard Shockey > Subject: Re: [stir] Your DC newsletter of the day.... > > The IAB is the best we have in the IETF context. The IAB maintains > relationships with various organizations and also interacts with regulators > in different areas. We obviously do the work with others, such as ISOC, > since there are lots of regulators out there... > > What the best way is to share (or exchange) information needs to be > determined on a case-by-case basis. I am happy to chat with you about what > should/could be done. > > Ciao > Hannes > > On 08/20/2013 06:52 PM, Brian Rosen wrote: >> Does the IETF have a way of supplying legislators with information? >> We probably would like to make them aware of our work. I know it was >> mentioned in FCC testimony, but do we have a more direct path? I'd be >> willing to work on this if there is a path. >> >> >> On Tue, Aug 20, 2013 at 12:42 PM, Richard Shockey > > wrote: >> >> Exactly ... essentially useless. >> >> -----Original Message----- >> From: stir-bounces@ietf.org >> [mailto:stir-bounces@ietf.org ] On >> Behalf Of >> Hadriel Kaplan >> Sent: Tuesday, August 20, 2013 12:12 PM >> To: Paul Kyzivat >> Cc: stir@ietf.org >> Subject: Re: [stir] Your DC newsletter of the day.... >> >> >> It was discussed in the FTC subcommittee hearing, for which the video >> recording is available here: >> > http://www.commerce.senate.gov/public/index.cfm?p=Hearings&ContentRecord_id= >> c1eec086-3512-4182-ae63-d60e68f4a532 >> > = >> c1eec086-3512-4182-ae63-d60e68f4a532> >> >> There was an email thread on this in STIR list starting here: >> http://www.ietf.org/mail-archive/web/stir/current/msg00762.html >> >> The two technologies discussed were Primus' TeleGuard, and Nomorobo. >> The >> Primus one has been around for a while. >> Unfortunately without STIR both of those "technologies" are easily >> defeat-able, afaict. >> >> -hadriel >> >> >> On Aug 20, 2013, at 11:56 AM, Paul Kyzivat > > wrote: >> >> > Richard, >> > >> > This letter says: "two robocall screening technologies were >> discussed in >> some detail, one of which has been in operation for six years." >> > >> > What technologies were these? >> > >> > Thanks, >> > Paul >> > >> > On 8/19/13 4:21 PM, Richard Shockey wrote: >> >> http://www.mccaskill.senate.gov/McCaskilltoUSTAandCTIA.pdf >> >> >> >> FYI . >> >> >> >> Richard Shockey >> >> Shockey Consulting >> >> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 >> >> 703.593.2683 > (at)shockey.us > >> >> skype-linkedin-facebook: rshockey101 >> >> http//www.sipforum.org > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From br@brianrosen.net Tue Aug 20 11:36:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA45D11E8133 for ; Tue, 20 Aug 2013 11:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.905 X-Spam-Level: X-Spam-Status: No, score=-101.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HMDc6bEBZUK for ; Tue, 20 Aug 2013 11:36:18 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAFC11E814F for ; Tue, 20 Aug 2013 11:36:17 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so754287pdj.17 for ; Tue, 20 Aug 2013 11:36:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jGT6N8MRa6NkN3cMS2SCx4dV3FP5500I7FraSIBXnUo=; b=FAIrIClb2rO8paP4eZedNQ7vguYtv26gn2NQcJizzZY4Wr5TQ00pgXvkNFp2j3rtMa Tbm144Pt2yYP+pEpKeWN109/fd4e2r+0LFc/OLS6zLEp+c01If+TRE26nDerpVuRRVLt GD1RFbLzGvn0p+B9pzD7eljQjk8DERIevQ845oFLWE4922PJ3DURlLviVTiVBFxZbA6G 5VzFiBw42DwJOSF+tCYSdZdFPgX3bLbJLbgIaXxGXqYBr9/+mVRSsAOBoFMujkCoqOLT ZYTpmeJ+O1v5Iun4UF56X+lzLXhshMwkeiGTStjDnNzyKXQaiY07yuxj+fS9hVFQz2gn oX1Q== X-Gm-Message-State: ALoCoQkFQrMYKQRYHiBaJajuFbSHluB/UFVQkfu5xEeYGLjG7FhsrwWJ2nBl3Z+QAP7yEJVJ2344 MIME-Version: 1.0 X-Received: by 10.68.143.38 with SMTP id sb6mr3574797pbb.44.1377023777564; Tue, 20 Aug 2013 11:36:17 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 20 Aug 2013 11:36:17 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> Date: Tue, 20 Aug 2013 14:36:17 -0400 Message-ID: From: Brian Rosen To: Michael Hammer Content-Type: multipart/alternative; boundary=047d7b2e3fbe1bfd6404e46555ee Cc: "stir@ietf.org" , "kent@bbn.com" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:36:23 -0000 --047d7b2e3fbe1bfd6404e46555ee Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think that I could come up with a reasonable way to display "this information is likely good, but could be inaccurate" in a way that most people can deal with it. It's always possible to threshold it at the device. We have scores on the existing service - it's just that the threshold is determined before the data gets to the device. Brian On Tue, Aug 20, 2013 at 2:20 PM, Michael Hammer < michael.hammer@yaanatech.com> wrote: > Great for nerds. **** > > ** ** > > But, I think if you tell the average person, **** > > that the call is 60% assured of coming from First National Bank, **** > > what does that mean?**** > > ** ** > > It means the telephone network is broken, **** > > since it doesn=92t know what it is doing.**** > > ** ** > > Mike**** > > ** ** > > ** ** > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf > Of *Brian Rosen > *Sent:* Tuesday, August 20, 2013 2:01 PM > *To:* Stephen Kent > > *Cc:* stir@ietf.org List > *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to Charter)= * > *** > > ** ** > > The score could be used by a smart device to display something > appropriate. A service provider could establish thresholds for dumb > devices.**** > > ** ** > > Lots of existing systems use scores for similar problems. The data is no= t > definitive, so instead of go/no go, you get a score. There are lots of > fields in these databases. The more input you provide, the more accurate > the result. **** > > ** ** > > The mechanics of the databases and scoring, and even using scores, is wel= l > established data science. The only new stuff here is the mechanics of > carrying it.**** > > ** ** > > Brian**** > > ** ** > > On Tue, Aug 20, 2013 at 1:44 PM, Stephen Kent wrote:**** > > Brian,**** > > ** ** > > There isn't a database that will supply a unique identifier for all > contexts. OTOH, if you are a US resident, we could get a pretty good sco= re > comparing your name to your phone number, and if we had an address, we > probably can get a pretty high score. That would provide a pretty > meaningful assurance on the name attached to a phone call if we could > manage to get the mechanics worked out. These databases exist in most > developed countries.**** > > Score? I hope we're not planning to send the score to the callee, as that > will probably > confuse them. If the score is for internal use by a service provider, the= n > there is the > risk that different providers will have different thresholds, which leads > to a different sort of confusion.**** > > ** ** > > This is much better than we have today, because in most cases there is no > attempt to validate the name when a service provider gets a new customer. > > If we could use these databases to score the name associated with the > number, especially if the originating service provider obtained and > supplied other information to the validation service (at the initiation o= f > service, and possibly periodically after), then the validation service > could provide a pretty decent score at the termination end.**** > > Are we talking about the VoIP version of "Name that Tune": > "it's got great lyrics and a good beat, so I give it a 7" > > Steve**** > > ** ** > --047d7b2e3fbe1bfd6404e46555ee Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I think that I could come up with a reasonable way to disp= lay "this information is likely good, but could be inaccurate" in= a way that most people can deal with it. =A0It's always possible to th= reshold it at the device.

We have scores on the existing service - it's just that = the threshold is determined before the data gets to the device.
<= br>
Brian



On Tue, Aug 20, 2013 at 2:20 PM, Michael= Hammer <michael.hammer@yaanatech.com> wrote:
=

Great for nerds.=A0

=A0

But, I think if you tell the average person, =

that the call is 60% assu= red of coming from First National Bank,

what does that mean?

=A0

It means the telephone ne= twork is broken,

since it doesn=92t know what it is doing.

=A0<= /p>

Mike

=A0<= /p>

=A0

From: stir-bounces@ietf.org [mailto:stir-= bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, August 20, 2013 2:01 PM
To: Stephen Kent


Cc: stir@ietf.org List
Subject: Re: [stir] Early= Homework (was Re: Moving from BOF to Charter)

=A0

The score could be used by a smart device to display something appropri= ate. =A0A service provider could establish thresholds for dumb devices.<= /u>

=A0

Lots of existing systems use scores for simi= lar problems. =A0The data is not definitive, so instead of go/no go, you ge= t a score. =A0There are lots of fields in these databases. =A0The more inpu= t you provide, the more accurate the result. =A0

=A0

The mechanics of the databases and scoring, and even using s= cores, is well established data science. =A0The only new stuff here is the = mechanics of carrying it.

=A0

Brian

=A0

On Tue, Aug 20, 2013 at 1:44 PM, Stephen Kent &= lt;kent@bbn.com> w= rote:

Brian,

=

=A0

=

There isn't a database that will supply a unique= identifier for all contexts. =A0OTOH, if you are a US resident, we could g= et a pretty good score comparing your name to your phone number, and if we = had an address, we probably can get a pretty high score. =A0That would prov= ide a pretty meaningful assurance on the name attached to a phone call if w= e could manage to get the mechanics worked out. =A0These databases exist in= most developed countries.

Score? I hope we're not plann= ing to send the score to the callee, as that will probably
confuse them.= If the score is for internal use by a service provider, then there is the<= br> risk that different providers will have different thresholds, which leads t= o a different sort of confusion.

=A0

This is = much better than we have today, because in most cases there is no attempt t= o validate the name when a service provider gets a new customer.

If = we could use these databases to score the name associated with the number, = especially if the originating service provider obtained and supplied other = information to the validation service (at the initiation of service, and po= ssibly periodically after), then the validation service could provide a pre= tty decent score at the termination end.

Are we talking about the VoIP ver= sion of "Name that Tune":
=A0 =A0 "it's got great lyr= ics and a good beat, so I give it a 7"

Steve

<= /div>

=A0

<= /blockquote>

--047d7b2e3fbe1bfd6404e46555ee-- From richard@shockey.us Tue Aug 20 11:46:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD9D21F9C56 for ; Tue, 20 Aug 2013 11:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.117 X-Spam-Level: X-Spam-Status: No, score=-102.117 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16DdhJKkwlkD for ; Tue, 20 Aug 2013 11:46:47 -0700 (PDT) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 5957E11E826D for ; Tue, 20 Aug 2013 11:46:39 -0700 (PDT) Received: (qmail 24526 invoked by uid 0); 20 Aug 2013 18:45:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.mail.unifiedlayer.com with SMTP; 20 Aug 2013 18:45:53 -0000 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:Date:Subject:In-Reply-To:References:Cc:To:From; bh=QsxhcqYyv6MKn1GiFAb7kxUYxLYvJpnB7P3gBDeyNNw=; b=HQrnLSVHHb6Z6WWpe6MuB5Qnd+fF7RO77PQUuVHkkvb2nDSj4KgbRawzri5IJFdx1nP8/SME+ivXE0cd9U2EghwJmJNn943I/ohg8ZkpiIPaACcbryFis7s4uCfBYKOe; Received: from [71.114.100.16] (port=54541 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBqwD-0007wq-Fp; Tue, 20 Aug 2013 12:45:53 -0600 From: "Richard Shockey" To: "'Brian Rosen'" , "'Stephen Kent'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520AE960.8020800@alum.mit.edu> <0C3446D4-1E1F-40D0-9E95-5A64078D0193@oracle.com> <38726EDA2109264987B45E29E758C4D6049AA750@MISOUT7MSGUSR9N.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3012AA54E2C@FHDP1LUMXC7V31.us.one.verizon.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090 603@bbn.com> In-Reply-To: Date: Tue, 20 Aug 2013 14:45:51 -0400 Message-ID: <013201ce9dd5$7f79d9d0$7e6d8d70$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0133_01CE9DB3.F868D610" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQHDEuIkAgFiOZEBpfjYOgI3GZrTAw9GpewBvldmIQGLSzD+AbpzlT0CJRpHVwHPxEdhAVpPQDMB4Wx7BAK0YOfgAuqDH9ICfOiUtAKG4/w8Ae44E8IBVzq3tpeeyMmQ X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:46:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0133_01CE9DB3.F868D610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The score could be used by a smart device to display something appropriate. A service provider could establish thresholds for dumb devices. Lots of existing systems use scores for similar problems. The data is not definitive, so instead of go/no go, you get a score. There are lots of fields in these databases. The more input you provide, the more accurate the result. [RS> ] We know .. Virtually all credit scoring systems and risk based authentication models do this. The financial services industry pioneered the technique. The mechanics of the databases and scoring, and even using scores, is well established data science. The only new stuff here is the mechanics of carrying it. [RS> ] but the mechanics of carrying it are the "bridge too far" for STIR. Brian ------=_NextPart_000_0133_01CE9DB3.F868D610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

The = score could be used by a smart device to display something appropriate. =  A service provider could establish thresholds for dumb = devices.

 

Lots of existing systems use scores for similar = problems.  The data is not definitive, so instead of go/no go, you = get a score.  There are lots of fields in these databases. =  The more input you provide, the more accurate the result. =  

[RS> ]  We know .. Virtually all credit scoring systems and = risk based authentication models do this.  The financial services = industry pioneered the technique.

 

The mechanics of the databases and scoring, and even = using scores, is well established data science.  The only new stuff = here is the mechanics of carrying it.

 

[RS> ] but  the mechanics of carrying it are the = “bridge too far” for STIR.

 

 

 

Brian

------=_NextPart_000_0133_01CE9DB3.F868D610-- From kent@bbn.com Tue Aug 20 12:16:27 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053A321F9D74 for ; Tue, 20 Aug 2013 12:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXw+6NXSdUMZ for ; Tue, 20 Aug 2013 12:16:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 33F7021F9D5A for ; Tue, 20 Aug 2013 12:16:20 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50055) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBrPf-000Htm-QA; Tue, 20 Aug 2013 15:16:19 -0400 Message-ID: <5213C083.90309@bbn.com> Date: Tue, 20 Aug 2013 15:16:19 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 19:16:27 -0000 Brian, Research performed at CMU a few years ago found that the vast majority of folks in their test cohort were unable to figure out what the lock icon in a browser meant, or even to notice its presence/absence reliably. So, tell me again how one displays a confidence rating for caller ID to this same set of folks in a way that is useful. The fact that the financial services industry uses scoring to deal with risks (internally) is, IMHO, irrelevant to this discussion. Steve From hannes.tschofenig@gmx.net Tue Aug 20 12:31:04 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1627611E826E for ; Tue, 20 Aug 2013 12:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvopg4grfADU for ; Tue, 20 Aug 2013 12:30:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id DBFC911E814E for ; Tue, 20 Aug 2013 12:30:58 -0700 (PDT) Received: from [172.16.254.200] ([195.149.218.67]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LiTF6-1VoEjU2suq-00chm1 for ; Tue, 20 Aug 2013 21:30:57 +0200 Message-ID: <5213C3F8.3040200@gmx.net> Date: Tue, 20 Aug 2013 21:31:04 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Kent References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> In-Reply-To: <5213C083.90309@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:w8G77OYCMDV0qG0aAWvVtJraP6HltmXscZxKa5Ls9MjdEKqeJfm 1UHecBedkH5LPVr4TqsNvo6od2GN1pz+bMQpeJuhGqZPcptXsiHSXQj0CxAeF9EYSdjxoGg Btd8gU4Liwy/NOZkeEXuqLoRg8tzf3MLksq/ZXZR8XuZqs+YOZlEHGV7a/Fo04L2I1fPUkB p1Sd2qsjWzi587hxNa2IA== Cc: "stir@ietf.org" , hannes.tschofenig@gmx.net, Brian Rosen Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 19:31:04 -0000 Hi Steve, I think that there are various aspects to this story. First, there is a user interface aspect that is quite important. Clearly, we have noticed that already with various other security protocols (and privacy mechanisms as well). While the IETF does not standardize user interfaces it would obviously be great if we could work with those who do this type of work. Second, there is the challenge that a lot of our technology is pretty complex and the chances that end users understand them is rather unlikely (since even we have problems understanding the bigger picture ourselves). But what is the conclusion? Should we stop working on security mechanisms because others don't understand them? Should we turn of security (like TLS) because people get confused by different colours various vendors use (in their attempt to differentiate themselves from their competitors)? I don't think that is the solution either. Ideally, we would like to provide a secure version only and, in some groups these issues actually got raised (if you think about the HTTP 2.0 discussions) and, as you are also aware, there are various companies who love insecure versions of protocols (so that they can build enterprise DPI boxes, aeh. content security devices). In this particular case it is even worse since we have to work around a broken legacy system and equally insecure VoIP deployments. There is the big transition problem. Of course, all this does not sound like the ingredients for an easy protocol design. So, what should we do? Ciao Hannes On 08/20/2013 09:16 PM, Stephen Kent wrote: > Brian, > > Research performed at CMU a few years ago found that the vast majority of > folks in their test cohort were unable to figure out what the lock icon > in a browser > meant, or even to notice its presence/absence reliably. > > So, tell me again how one displays a confidence rating for caller ID to > this same > set of folks in a way that is useful. > > The fact that the financial services industry uses scoring to deal with > risks (internally) > is, IMHO, irrelevant to this discussion. > > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Tue Aug 20 13:24:05 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABED111E82A3 for ; Tue, 20 Aug 2013 13:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsvA9wQhwgr4 for ; Tue, 20 Aug 2013 13:24:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4E97911E829B for ; Tue, 20 Aug 2013 13:24:00 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7KKNu8w026434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 20:23:57 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KKNtMD017842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 20:23:55 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KKNsGu023449; Tue, 20 Aug 2013 20:23:54 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Aug 2013 13:23:54 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5213C3F8.3040200@gmx.net> Date: Tue, 20 Aug 2013 16:23:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <860A3C3D-F963-4413-9C94-606145BD1936@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org List" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 20:24:05 -0000 I'm not sure how you mean your questions - what're you applying them to? = To calling name, or to calling number? ISTM using a "score" based model to determine authenticity/validity is = reasonable and useful in some specific applications when a machine can = make a determination of good/bad based on score thresholds, and the = input weights to the score and their thresholds can be tweaked by = administrators or vendors based on experience and prior results. But I = don't know if such a thing would make any sense whatsoever for calling = name, and regardless of it does or not: to expect end users to grok = scores is a bad joke. Fundamentally most average PSTN users expect the calling number, and the = calling name, to be legitimate. We know they're not. STIR is chartered = (or will be soon) to address the calling number. We're pretty sure we = know ways to fix that from a protocol and technology perspective, in = practical ways (whether the market adopts is a different question). I don't think anyone has any practical idea for how to truly "fix" = calling name anytime soon. The most reasonable thing to do, I think, is = to do nothing substantively different for calling name right now. = There's a 3rd-party CNAM DB model, there's a LIDB model, and there's a = PAI display-name model. None of them are perfect, and they each have = better/worse properties. The good news is the STIR calling number validation should help the = calling name issue, by at least helping the fraud investigators know = which originating carrier the call came from. It might also enable the = blacklisting/whitelisting mechanisms to actually work, which itself = might help weed out bad calling name generators. -hadriel On Aug 20, 2013, at 3:31 PM, Hannes Tschofenig = wrote: > Hi Steve, >=20 > I think that there are various aspects to this story. >=20 > First, there is a user interface aspect that is quite important. = Clearly, we have noticed that already with various other security = protocols (and privacy mechanisms as well). While the IETF does not = standardize user interfaces it would obviously be great if we could work = with those who do this type of work. >=20 > Second, there is the challenge that a lot of our technology is pretty = complex and the chances that end users understand them is rather = unlikely (since even we have problems understanding the bigger picture = ourselves). >=20 > But what is the conclusion? Should we stop working on security = mechanisms because others don't understand them? Should we turn of = security (like TLS) because people get confused by different colours = various vendors use (in their attempt to differentiate themselves from = their competitors)? >=20 > I don't think that is the solution either. >=20 > Ideally, we would like to provide a secure version only and, in some = groups these issues actually got raised (if you think about the HTTP 2.0 = discussions) and, as you are also aware, there are various companies who = love insecure versions of protocols (so that they can build enterprise = DPI boxes, aeh. content security devices). In this particular case it is = even worse since we have to work around a broken legacy system and = equally insecure VoIP deployments. There is the big transition problem. >=20 > Of course, all this does not sound like the ingredients for an easy = protocol design. >=20 > So, what should we do? >=20 > Ciao > Hannes >=20 > On 08/20/2013 09:16 PM, Stephen Kent wrote: >> Brian, >>=20 >> Research performed at CMU a few years ago found that the vast = majority of >> folks in their test cohort were unable to figure out what the lock = icon >> in a browser >> meant, or even to notice its presence/absence reliably. >>=20 >> So, tell me again how one displays a confidence rating for caller ID = to >> this same >> set of folks in a way that is useful. >>=20 >> The fact that the financial services industry uses scoring to deal = with >> risks (internally) >> is, IMHO, irrelevant to this discussion. >>=20 >> Steve >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From kent@bbn.com Tue Aug 20 13:24:05 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36E711E829B for ; Tue, 20 Aug 2013 13:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBUKokvpiMhF for ; Tue, 20 Aug 2013 13:24:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1944811E829A for ; Tue, 20 Aug 2013 13:23:59 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50147) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VBsT8-000J9R-VF; Tue, 20 Aug 2013 16:23:59 -0400 Message-ID: <5213D05E.4080807@bbn.com> Date: Tue, 20 Aug 2013 16:23:58 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hannes Tschofenig References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> In-Reply-To: <5213C3F8.3040200@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 20:24:06 -0000 Hannes, > Hi Steve, > > I think that there are various aspects to this story. > > First, there is a user interface aspect that is quite important. > Clearly, we have noticed that already with various other security > protocols (and privacy mechanisms as well). While the IETF does not > standardize user interfaces it would obviously be great if we could > work with those who do this type of work. sounds like an IRTF task, for now. > > Second, there is the challenge that a lot of our technology is pretty > complex and the chances that end users understand them is rather > unlikely (since even we have problems understanding the bigger picture > ourselves). agreed! > But what is the conclusion? Should we stop working on security > mechanisms because others don't understand them? Should we turn of > security (like TLS) because people get confused by different colours > various vendors use (in their attempt to differentiate themselves from > their competitors)? One conclusion is that this may not be ready for engineering. It certainly seems to be out of scope for this WG at this time. > Ideally, we would like to provide a secure version only and, in some > groups these issues actually got raised (if you think about the HTTP > 2.0 discussions) and, as you are also aware, there are various > companies who love insecure versions of protocols (so that they can > build enterprise DPI boxes, aeh. content security devices). In this > particular case it is even worse since we have to work around a broken > legacy system and equally insecure VoIP deployments. There is the big > transition problem. see comments above. > Of course, all this does not sound like the ingredients for an easy > protocol design. > > So, what should we do? 1. agree that we're going to pursue only calling # security measures until this WG re-charters. 2. consider an IAB workshop or an IRTF group to deal with the issue of how to represent individual or org ID info to users (not just VoIP) users in a way that does more god than harm. Steve From br@brianrosen.net Tue Aug 20 13:45:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7914A11E82B0 for ; Tue, 20 Aug 2013 13:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.579 X-Spam-Level: X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKb5JPf49PM7 for ; Tue, 20 Aug 2013 13:45:10 -0700 (PDT) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9237311E82BC for ; Tue, 20 Aug 2013 13:45:10 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md4so839706pbc.2 for ; Tue, 20 Aug 2013 13:45:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eiYjsiPDp7mc1sdK2HM5HJUm6wnsDqL3JIJ8ilfZ1kY=; b=dtEEmndwh/9xWfNAhuB2Y4kzhutSRBM5B+4VkSYZHEQnkz+3dIdmXhdN2maeyZUc3n 2lTVYLK0SsE34cVPshgWC3yN93iVqRJJOIABx+fAEEb4eqGC4Mc5kNowVwXm3aV6Lvri BLTpMsIOQjb8QGqu6LGD4SljYaePhpbduCFSlysPjvOqfsE3FERfLjsnJRLF6iPk9pU8 nLdZHiw+Y4Wa8iBwzTKN5Yn2LhYt29RV0B7x6HY++pRitysCnJ3HFMI5mohsFci7lI8o wy4argo8kINFx63MrKovLBt59szLaU3d20slG9+Nb8s4oQOL5XOUHAwd6K0PCvgvfbcf fURQ== X-Gm-Message-State: ALoCoQneyWDnIrHy9DGpEh/lxxT9T1qfHiGAKJAzmGM6ugWxWmrlGgmEz7hKzjRMR0+Q5S5eSWSy MIME-Version: 1.0 X-Received: by 10.68.12.97 with SMTP id x1mr3906848pbb.150.1377031509298; Tue, 20 Aug 2013 13:45:09 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 20 Aug 2013 13:45:09 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <5213D05E.4080807@bbn.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <520BD490.4000701@alum.mit.edu> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> <5213D05E.4080807@bbn.com> Date: Tue, 20 Aug 2013 16:45:09 -0400 Message-ID: From: Brian Rosen To: Stephen Kent Content-Type: multipart/alternative; boundary=bcaec5215f91f4e22e04e46721d4 Cc: "stir@ietf.org" , Hannes Tschofenig Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 20:45:15 -0000 --bcaec5215f91f4e22e04e46721d4 Content-Type: text/plain; charset=ISO-8859-1 I don't think the IETF has the expertise, even in IRTF, to do user interface design. We don't need to do any. If we carry a score, the device UI designers and the service providers can deal with it. We are simply acknowledging that there is no certainty, and we're offering to provide the level of certainty we have. Since there are plenty of examples of devices and services that use these kinds of scores, we don't need to know how they work, or what any UI will do with them. We don't even need to offer advise on what to do. Brian On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent wrote: > Hannes, > > Hi Steve, >> >> I think that there are various aspects to this story. >> >> First, there is a user interface aspect that is quite important. Clearly, >> we have noticed that already with various other security protocols (and >> privacy mechanisms as well). While the IETF does not standardize user >> interfaces it would obviously be great if we could work with those who do >> this type of work. >> > sounds like an IRTF task, for now. > > >> Second, there is the challenge that a lot of our technology is pretty >> complex and the chances that end users understand them is rather unlikely >> (since even we have problems understanding the bigger picture ourselves). >> > agreed! > > But what is the conclusion? Should we stop working on security mechanisms >> because others don't understand them? Should we turn of security (like TLS) >> because people get confused by different colours various vendors use (in >> their attempt to differentiate themselves from their competitors)? >> > One conclusion is that this may not be ready for engineering. > > It certainly seems to be out of scope for this WG at this time. > > Ideally, we would like to provide a secure version only and, in some >> groups these issues actually got raised (if you think about the HTTP 2.0 >> discussions) and, as you are also aware, there are various companies who >> love insecure versions of protocols (so that they can build enterprise DPI >> boxes, aeh. content security devices). In this particular case it is even >> worse since we have to work around a broken legacy system and equally >> insecure VoIP deployments. There is the big transition problem. >> > see comments above. > > Of course, all this does not sound like the ingredients for an easy >> protocol design. >> >> So, what should we do? >> > 1. agree that we're going to pursue only calling # security measures until > this WG re-charters. > > 2. consider an IAB workshop or an IRTF group to deal with the issue of how > to represent individual or org ID info to users (not just VoIP) users in a > way > that does more god than harm. > > > Steve > ______________________________**_________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/**listinfo/stir > --bcaec5215f91f4e22e04e46721d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't think the IETF has the expertise, even in IRTF= , to do user interface design. =A0We don't need to do any. =A0If we car= ry a score, the device UI designers and the service providers can deal with= it. =A0We are simply acknowledging that there is no certainty, and we'= re offering to provide the level of certainty we have. =A0Since there are p= lenty of examples of devices and services that use these kinds of scores, w= e don't need to know how they work, or what any UI will do with them. = =A0We don't even need to offer advise on what to do.=A0

Brian


On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent <kent@bbn.com= > wrote:
Hannes,

Hi Steve,

I think that there are various aspects to this story.

First, there is a user interface aspect that is quite important. Clearly, w= e have noticed that already with various other security protocols (and priv= acy mechanisms as well). While the IETF does not standardize user interface= s it would obviously be great if we could work with those who do this type = of work.
sounds like an IRTF task, for now.


Second, there is the challenge that a lot of our technology is pretty compl= ex and the chances that end users understand them is rather unlikely (since= even we have problems understanding the bigger picture ourselves).
agreed!

But what is the conclusion? Should we stop working on security mechanisms b= ecause others don't understand them? Should we turn of security (like T= LS) because people get confused by different colours various vendors use (i= n their attempt to differentiate themselves from their competitors)?
One conclusion is that this may not be ready for engineering.

It certainly seems to be out of scope for this WG at this time.

Ideally, we would like to provide a secure version only and, in some groups= these issues actually got raised (if you think about the HTTP 2.0 discussi= ons) and, as you are also aware, there are various companies who love insec= ure versions of protocols (so that they can build enterprise DPI boxes, aeh= . content security devices). In this particular case it is even worse since= we have to work around a broken legacy system and equally insecure VoIP de= ployments. There is the big transition problem.
see comments above.

Of course, all this does not sound like the ingredients for an easy protoco= l design.

So, what should we do?
1. agree that we're going to pursue only calling # security measures un= til
this WG re-charters.

2. consider an IAB workshop or an IRTF group to deal with the issue of how<= br> to represent individual or org ID info to users (not just VoIP) users in a = way
that does more god than harm.


Steve
_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--bcaec5215f91f4e22e04e46721d4-- From pkyzivat@alum.mit.edu Tue Aug 20 14:37:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D62A11E82D8 for ; Tue, 20 Aug 2013 14:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vzlGbxWTdNr for ; Tue, 20 Aug 2013 14:37:52 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA4111E8280 for ; Tue, 20 Aug 2013 14:37:52 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta02.westchester.pa.mail.comcast.net with comcast id F0DE1m00116LCl0519drgd; Tue, 20 Aug 2013 21:37:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id F9dr1m00W3ZTu2S3S9dr57; Tue, 20 Aug 2013 21:37:51 +0000 Message-ID: <5213E1AE.5090206@alum.mit.edu> Date: Tue, 20 Aug 2013 17:37:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> <5213D05E.4080807@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377034671; bh=uVpqjfJz4yyfRDYhwWZ41OmexexIMswsTs0BidH7lbs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RdUfd1aQu1L5s+/AjtPQSCerVNl1+zqulzoghbobLblJMqxCEmjxgwKU0ylnOiHiS L40aDmMOYrJT2drwTRK7d7jl9hIdlxzkSJ9tnbSuEqXfBKuEYVktHML7UQGL2PTNZ5 gLpHkwCRZgbmatQigKZUVhsC78AenxJkatZTaDCXyKaS+VRhBSjJk4Njv2+KkjoJYO ADQYZlvJyK13XdeEG9gazibBuSPsCDeM+BYlmcxDFpO0Yxxv4mKh93L0AKYf+BU+Jj AMWqoZfwS/UF4Blal6UOk5DLhEZ6RR4LHiaOgcz/EWPHQ9yXH9g9n3hWclr8JNykOr Eeh8Xw1wz7m7w== Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 21:37:57 -0000 On 8/20/13 4:45 PM, Brian Rosen wrote: > I don't think the IETF has the expertise, even in IRTF, to do user > interface design. We don't need to do any. If we carry a score, the > device UI designers and the service providers can deal with it. IMO a "score" (in the sense of a single number) is probably also not the most appropriate input to presentation solutions. I expect that we will likely have an assortment of data that can be used to assess the validity of the name. Better to just provide all that to the UI and let it do its thing, rather than boiling it down into a number (and discarding useful information in the process.) For instance, if the name in the request is signed, then the identity of the signer may be useful. And stuff that gets looked up at the receiving end can have arbitrary properties. > We are > simply acknowledging that there is no certainty, and we're offering to > provide the level of certainty we have. Since there are plenty of > examples of devices and services that use these kinds of scores, we > don't need to know how they work, or what any UI will do with them. We > don't even need to offer advise on what to do. For now I think less is more. In that respect I agree with you. Thanks, Paul > Brian > > > On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent > wrote: > > Hannes, > > Hi Steve, > > I think that there are various aspects to this story. > > First, there is a user interface aspect that is quite important. > Clearly, we have noticed that already with various other > security protocols (and privacy mechanisms as well). While the > IETF does not standardize user interfaces it would obviously be > great if we could work with those who do this type of work. > > sounds like an IRTF task, for now. > > > Second, there is the challenge that a lot of our technology is > pretty complex and the chances that end users understand them is > rather unlikely (since even we have problems understanding the > bigger picture ourselves). > > agreed! > > But what is the conclusion? Should we stop working on security > mechanisms because others don't understand them? Should we turn > of security (like TLS) because people get confused by different > colours various vendors use (in their attempt to differentiate > themselves from their competitors)? > > One conclusion is that this may not be ready for engineering. > > It certainly seems to be out of scope for this WG at this time. > > Ideally, we would like to provide a secure version only and, in > some groups these issues actually got raised (if you think about > the HTTP 2.0 discussions) and, as you are also aware, there are > various companies who love insecure versions of protocols (so > that they can build enterprise DPI boxes, aeh. content security > devices). In this particular case it is even worse since we have > to work around a broken legacy system and equally insecure VoIP > deployments. There is the big transition problem. > > see comments above. > > Of course, all this does not sound like the ingredients for an > easy protocol design. > > So, what should we do? > > 1. agree that we're going to pursue only calling # security measures > until > this WG re-charters. > > 2. consider an IAB workshop or an IRTF group to deal with the issue > of how > to represent individual or org ID info to users (not just VoIP) > users in a way > that does more god than harm. > > > Steve > _________________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/__listinfo/stir > > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From br@brianrosen.net Tue Aug 20 14:43:03 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBF811E82E0 for ; Tue, 20 Aug 2013 14:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.056 X-Spam-Level: X-Spam-Status: No, score=-101.056 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGfWo0MKNwfK for ; Tue, 20 Aug 2013 14:42:56 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1936F11E82D8 for ; Tue, 20 Aug 2013 14:42:50 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so954245pdj.29 for ; Tue, 20 Aug 2013 14:42:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZWL2aH4Gaus1cKrZ3NGHRHHxbt2H/T76u/08BvxviYY=; b=gXDgSq/rf11w6h4hjNcJf0Ck6A7MVzqiIl/sEFxcedFS3lT8NsEtYhDDTqNMoBvVRC loPSwcCDIO8Y4WKiYR1xxkEdIIsxa4eqavO2HermoDlH63kqG5oWmd7pfcHpaIpD3Jvn MJ7/eIO5pTcVlsRfiThnE3mp3HVzuO6bZxc391ZNbcrIQjqWoYSXcBBd2ffRZJIdkKKf +Fvp4iQUrWuKTppW1AZj3T5ev2ZljG+vG91+CY/1HIU4eRe9x3IUkHdI0JO+tpqohQya JDz4MV/GcYiXzWoZRzumr1M6xDhTHXFIWXVOuW3RHhRkc/S04AKSxl7v/Pv86BPD87yQ qk5w== X-Gm-Message-State: ALoCoQlZIbIwa7nEVv+XeENypTcaS1allVWnVRHwF5muW0xVq/COgvVdtfOkBWlsSb4pKSEcgpWh MIME-Version: 1.0 X-Received: by 10.68.131.168 with SMTP id on8mr4219978pbb.97.1377034967974; Tue, 20 Aug 2013 14:42:47 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 20 Aug 2013 14:42:47 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <5213E1AE.5090206@alum.mit.edu> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> <5213D05E.4080807@bbn.com> <5213E1AE.5090206@alum.mit.edu> Date: Tue, 20 Aug 2013 17:42:47 -0400 Message-ID: From: Brian Rosen To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c35c601c16ac04e467f012 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 21:43:06 -0000 --001a11c35c601c16ac04e467f012 Content-Type: text/plain; charset=ISO-8859-1 No objection to carrying more, but probably we have to standardize what more is, and that may blow up the problem. I can look into that aspect as it applies to other domains where the same database is used. I do think we have to include the identity of the validation service, but I think that would in inherent in the mechanism one way or another. Can't have the caller or the originating SP mucking with the score, can we? Brian On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat wrote: > On 8/20/13 4:45 PM, Brian Rosen wrote: > >> I don't think the IETF has the expertise, even in IRTF, to do user >> interface design. We don't need to do any. If we carry a score, the >> device UI designers and the service providers can deal with it. >> > > IMO a "score" (in the sense of a single number) is probably also not the > most appropriate input to presentation solutions. I expect that we will > likely have an assortment of data that can be used to assess the validity > of the name. Better to just provide all that to the UI and let it do its > thing, rather than boiling it down into a number (and discarding useful > information in the process.) > > For instance, if the name in the request is signed, then the identity of > the signer may be useful. And stuff that gets looked up at the receiving > end can have arbitrary properties. > > > We are >> simply acknowledging that there is no certainty, and we're offering to >> provide the level of certainty we have. Since there are plenty of >> examples of devices and services that use these kinds of scores, we >> don't need to know how they work, or what any UI will do with them. We >> don't even need to offer advise on what to do. >> > > For now I think less is more. In that respect I agree with you. > > Thanks, > Paul > > > > Brian >> >> >> On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent > > wrote: >> >> Hannes, >> >> Hi Steve, >> >> I think that there are various aspects to this story. >> >> First, there is a user interface aspect that is quite important. >> Clearly, we have noticed that already with various other >> security protocols (and privacy mechanisms as well). While the >> IETF does not standardize user interfaces it would obviously be >> great if we could work with those who do this type of work. >> >> sounds like an IRTF task, for now. >> >> >> Second, there is the challenge that a lot of our technology is >> pretty complex and the chances that end users understand them is >> rather unlikely (since even we have problems understanding the >> bigger picture ourselves). >> >> agreed! >> >> But what is the conclusion? Should we stop working on security >> mechanisms because others don't understand them? Should we turn >> of security (like TLS) because people get confused by different >> colours various vendors use (in their attempt to differentiate >> themselves from their competitors)? >> >> One conclusion is that this may not be ready for engineering. >> >> It certainly seems to be out of scope for this WG at this time. >> >> Ideally, we would like to provide a secure version only and, in >> some groups these issues actually got raised (if you think about >> the HTTP 2.0 discussions) and, as you are also aware, there are >> various companies who love insecure versions of protocols (so >> that they can build enterprise DPI boxes, aeh. content security >> devices). In this particular case it is even worse since we have >> to work around a broken legacy system and equally insecure VoIP >> deployments. There is the big transition problem. >> >> see comments above. >> >> Of course, all this does not sound like the ingredients for an >> easy protocol design. >> >> So, what should we do? >> >> 1. agree that we're going to pursue only calling # security measures >> until >> this WG re-charters. >> >> 2. consider an IAB workshop or an IRTF group to deal with the issue >> of how >> to represent individual or org ID info to users (not just VoIP) >> users in a way >> that does more god than harm. >> >> >> Steve >> ______________________________**___________________ >> >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/stir >> >> > >> >> >> >> >> >> ______________________________**_________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/**listinfo/stir >> >> > ______________________________**_________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/**listinfo/stir > --001a11c35c601c16ac04e467f012 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No objection to carrying more, but probably we have to sta= ndardize what more is, and that may blow up the problem. =A0I can look into= that aspect as it applies to other domains where the same database is used= .

I do think we have to include the identity of the validation= service, but I think that would in inherent in the mechanism one way or an= other. =A0Can't have the caller or the originating SP mucking with the = score, can we?

Brian


On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 8/20/13 4:45 PM, Brian = Rosen wrote:
I don't think the IETF has the expertise, even in IRTF, to do user
interface design. =A0We don't need to do any. =A0If we carry a score, t= he
device UI designers and the service providers can deal with it.

IMO a "score" (in the sense of a single number) is probably also = not the most appropriate input to presentation solutions. I expect that we = will likely have an assortment of data that can be used to assess the valid= ity of the name. Better to just provide all that to the UI and let it do it= s thing, rather than boiling it down into a number (and discarding useful i= nformation in the process.)

For instance, if the name in the request is signed, then the identity of th= e signer may be useful. And stuff that gets looked up at the receiving end = can have arbitrary properties.


We are
simply acknowledging that there is no certainty, and we're offering to<= br> provide the level of certainty we have. =A0Since there are plenty of
examples of devices and services that use these kinds of scores, we
don't need to know how they work, or what any UI will do with them. =A0= We
don't even need to offer advise on what to do.

For now I think less is more. In that respect I agree with you.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul



Brian


On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent <kent@bbn.com
<mailto:kent@bbn.com>> wrote:

=A0 =A0 Hannes,

=A0 =A0 =A0 =A0 Hi Steve,

=A0 =A0 =A0 =A0 I think that there are various aspects to this story.

=A0 =A0 =A0 =A0 First, there is a user interface aspect that is quite impor= tant.
=A0 =A0 =A0 =A0 Clearly, we have noticed that already with various other =A0 =A0 =A0 =A0 security protocols (and privacy mechanisms as well). While = the
=A0 =A0 =A0 =A0 IETF does not standardize user interfaces it would obviousl= y be
=A0 =A0 =A0 =A0 great if we could work with those who do this type of work.=

=A0 =A0 sounds like an IRTF task, for now.


=A0 =A0 =A0 =A0 Second, there is the challenge that a lot of our technology= is
=A0 =A0 =A0 =A0 pretty complex and the chances that end users understand th= em is
=A0 =A0 =A0 =A0 rather unlikely (since even we have problems understanding = the
=A0 =A0 =A0 =A0 bigger picture ourselves).

=A0 =A0 agreed!

=A0 =A0 =A0 =A0 But what is the conclusion? Should we stop working on secur= ity
=A0 =A0 =A0 =A0 mechanisms because others don't understand them? Should= we turn
=A0 =A0 =A0 =A0 of security (like TLS) because people get confused by diffe= rent
=A0 =A0 =A0 =A0 colours various vendors use (in their attempt to differenti= ate
=A0 =A0 =A0 =A0 themselves from their competitors)?

=A0 =A0 One conclusion is that this may not be ready for engineering.

=A0 =A0 It certainly seems to be out of scope for this WG at this time.

=A0 =A0 =A0 =A0 Ideally, we would like to provide a secure version only and= , in
=A0 =A0 =A0 =A0 some groups these issues actually got raised (if you think = about
=A0 =A0 =A0 =A0 the HTTP 2.0 discussions) and, as you are also aware, there= are
=A0 =A0 =A0 =A0 various companies who love insecure versions of protocols (= so
=A0 =A0 =A0 =A0 that they can build enterprise DPI boxes, aeh. content secu= rity
=A0 =A0 =A0 =A0 devices). In this particular case it is even worse since we= have
=A0 =A0 =A0 =A0 to work around a broken legacy system and equally insecure = VoIP
=A0 =A0 =A0 =A0 deployments. There is the big transition problem.

=A0 =A0 see comments above.

=A0 =A0 =A0 =A0 Of course, all this does not sound like the ingredients for= an
=A0 =A0 =A0 =A0 easy protocol design.

=A0 =A0 =A0 =A0 So, what should we do?

=A0 =A0 1. agree that we're going to pursue only calling # security mea= sures
=A0 =A0 until
=A0 =A0 this WG re-charters.

=A0 =A0 2. consider an IAB workshop or an IRTF group to deal with the issue=
=A0 =A0 of how
=A0 =A0 to represent individual or org ID info to users (not just VoIP)
=A0 =A0 users in a way
=A0 =A0 that does more god than harm.


=A0 =A0 Steve
=A0 =A0 _________________________________________________

=A0 =A0 stir mailing list
=A0 =A0 stir@ietf.org <mailto:stir@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/stir
=A0 =A0 <https://www.ietf.org/mailman/listinfo/stir>





_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--001a11c35c601c16ac04e467f012-- From timothy.dwight@verizon.com Tue Aug 20 15:12:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC8E11E82F3 for ; Tue, 20 Aug 2013 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCEhPos-H-9n for ; Tue, 20 Aug 2013 15:12:29 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1063311E82F0 for ; Tue, 20 Aug 2013 15:12:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe03.verizonbusiness.com with ESMTP; 20 Aug 2013 22:12:25 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,922,1367971200"; d="scan'208,217";a="540517939" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 20 Aug 2013 22:12:25 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Tue, 20 Aug 2013 18:12:25 -0400 To: Brian Rosen , Paul Kyzivat Date: Tue, 20 Aug 2013 18:12:24 -0400 Thread-Topic: [stir] Early Homework (was Re: Moving from BOF to Charter) Thread-Index: Ac6d7mKrXbpM/eAwS4ikg6O3XsAS6gAA6Ydw Message-ID: <2B0F677F0B95454297753F58D4A07FA3012AEC2C55@FHDP1LUMXC7V31.us.one.verizon.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> <5213D05E.4080807@bbn.com> <5213E1AE.5090206@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2B0F677F0B95454297753F58D4A07FA3012AEC2C55FHDP1LUMXC7V3_" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 22:12:35 -0000 --_000_2B0F677F0B95454297753F58D4A07FA3012AEC2C55FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the originating SP may in many cases *be* the validator. But I agr= ee with Paul that it should be visible to the called party which entity is = making the assertion. Some care will obviously have to be taken to ensure = this isn't spoofed, since claiming to be a trustworthy validator is an obvi= ous attack vector. tim From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Tuesday, August 20, 2013 4:43 PM To: Paul Kyzivat Cc: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) No objection to carrying more, but probably we have to standardize what mor= e is, and that may blow up the problem. I can look into that aspect as it = applies to other domains where the same database is used. I do think we have to include the identity of the validation service, but I= think that would in inherent in the mechanism one way or another. Can't h= ave the caller or the originating SP mucking with the score, can we? Brian On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat > wrote: On 8/20/13 4:45 PM, Brian Rosen wrote: I don't think the IETF has the expertise, even in IRTF, to do user interface design. We don't need to do any. If we carry a score, the device UI designers and the service providers can deal with it. IMO a "score" (in the sense of a single number) is probably also not the mo= st appropriate input to presentation solutions. I expect that we will likel= y have an assortment of data that can be used to assess the validity of the= name. Better to just provide all that to the UI and let it do its thing, r= ather than boiling it down into a number (and discarding useful information= in the process.) For instance, if the name in the request is signed, then the identity of th= e signer may be useful. And stuff that gets looked up at the receiving end = can have arbitrary properties. We are simply acknowledging that there is no certainty, and we're offering to provide the level of certainty we have. Since there are plenty of examples of devices and services that use these kinds of scores, we don't need to know how they work, or what any UI will do with them. We don't even need to offer advise on what to do. For now I think less is more. In that respect I agree with you. Thanks, Paul Brian On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent >> wrote: Hannes, Hi Steve, I think that there are various aspects to this story. First, there is a user interface aspect that is quite important. Clearly, we have noticed that already with various other security protocols (and privacy mechanisms as well). While the IETF does not standardize user interfaces it would obviously be great if we could work with those who do this type of work. sounds like an IRTF task, for now. Second, there is the challenge that a lot of our technology is pretty complex and the chances that end users understand them is rather unlikely (since even we have problems understanding the bigger picture ourselves). agreed! But what is the conclusion? Should we stop working on security mechanisms because others don't understand them? Should we turn of security (like TLS) because people get confused by different colours various vendors use (in their attempt to differentiate themselves from their competitors)? One conclusion is that this may not be ready for engineering. It certainly seems to be out of scope for this WG at this time. Ideally, we would like to provide a secure version only and, in some groups these issues actually got raised (if you think about the HTTP 2.0 discussions) and, as you are also aware, there are various companies who love insecure versions of protocols (so that they can build enterprise DPI boxes, aeh. content security devices). In this particular case it is even worse since we have to work around a broken legacy system and equally insecure VoIP deployments. There is the big transition problem. see comments above. Of course, all this does not sound like the ingredients for an easy protocol design. So, what should we do? 1. agree that we're going to pursue only calling # security measures until this WG re-charters. 2. consider an IAB workshop or an IRTF group to deal with the issue of how to represent individual or org ID info to users (not just VoIP) users in a way that does more god than harm. Steve _________________________________________________ stir mailing list stir@ietf.org > https://www.ietf.org/mailman/__listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_2B0F677F0B95454297753F58D4A07FA3012AEC2C55FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the originating SP= may in many cases *be* the validator.  But I agree with Paul t= hat it should be visible to the called party which entity is making the ass= ertion.  Some care will obviously have to be taken to ensure this isn&= #8217;t spoofed, since claiming to be a trustworthy validator is an obvious= attack vector.

 

tim

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.o= rg] On Behalf Of Brian Rosen
Sent: Tuesday, August 20, 201= 3 4:43 PM
To: Paul Kyzivat
Cc: stir@ietf.org
Subj= ect: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

 

No objection to carrying more, but probably we have to standar= dize what more is, and that may blow up the problem.  I can look into = that aspect as it applies to other domains where the same database is used.=

 

I do think we have to include the identity of the valida= tion service, but I think that would in inherent in the mechanism one way o= r another.  Can't have the caller or the originating SP mucking with t= he score, can we?

 =

Brian

<= div>

 

On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat &= lt;pkyzivat@alum= .mit.edu> wrote:

On 8/20/13 = 4:45 PM, Brian Rosen wrote:

I don't thin= k the IETF has the expertise, even in IRTF, to do user
interface design.=  We don't need to do any.  If we carry a score, the
device UI= designers and the service providers can deal with it.

 

IMO a "= score" (in the sense of a single number) is probably also not the most= appropriate input to presentation solutions. I expect that we will likely = have an assortment of data that can be used to assess the validity of the n= ame. Better to just provide all that to the UI and let it do its thing, rat= her than boiling it down into a number (and discarding useful information i= n the process.)

For instance, if the name in the request is signed, = then the identity of the signer may be useful. And stuff that gets looked u= p at the receiving end can have arbitrary properties.

 

We are=
simply acknowledging that there is no certainty, and we're offering to<= br>provide the level of certainty we have.  Since there are plenty of<= br>examples of devices and services that use these kinds of scores, we
d= on't need to know how they work, or what any UI will do with them.  We=
don't even need to offer advise on what to do.

 

For now I think less is more. In that respect I= agree with you.

        Thanks,
   = ;     Paul


Br= ian


On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent <kent@bbn.com

<mailto:kent@bbn.com>> wrote:

    Han= nes,

        Hi Steve,

    &nbs= p;   I think that there are various aspects to this story.

&nbs= p;       First, there is a user interface aspect that is qui= te important.
        Clearly, we have noticed that = already with various other
        security protocol= s (and privacy mechanisms as well). While the
       = ; IETF does not standardize user interfaces it would obviously be
 =       great if we could work with those who do this type of= work.

    sounds like an IRTF task, for now.


&= nbsp;       Second, there is the challenge that a lot of our= technology is
        pretty complex and the chance= s that end users understand them is
        rather u= nlikely (since even we have problems understanding the
    &nb= sp;   bigger picture ourselves).

    agreed!

&= nbsp;       But what is the conclusion? Should we stop worki= ng on security
        mechanisms because others don= 't understand them? Should we turn
        of securi= ty (like TLS) because people get confused by different
    &nb= sp;   colours various vendors use (in their attempt to differentiate        themselves from their competitors)?

&n= bsp;   One conclusion is that this may not be ready for engineering.
    It certainly seems to be out of scope for this WG at th= is time.

        Ideally, we would like to provi= de a secure version only and, in
        some groups= these issues actually got raised (if you think about
    &nbs= p;   the HTTP 2.0 discussions) and, as you are also aware, there are        various companies who love insecure versions = of protocols (so
        that they can build enterpr= ise DPI boxes, aeh. content security
        devices= ). In this particular case it is even worse since we have
    =     to work around a broken legacy system and equally insecure Vo= IP
        deployments. There is the big transition = problem.

    see comments above.

    &nbs= p;   Of course, all this does not sound like the ingredients for an        easy protocol design.

    &nb= sp;   So, what should we do?

    1. agree that we're = going to pursue only calling # security measures
    until
=     this WG re-charters.

    2. consider an IAB = workshop or an IRTF group to deal with the issue
    of how    to represent individual or org ID info to users (not just Vo= IP)
    users in a way
    that does more god tha= n harm.


    Steve

    ________________________________________________= _


    stir mailing li= st
    stir= @ietf.org <mailto:stir@ietf.org>

  &nbs= p; https://www.ietf.org/mailman/__listinfo/stir
    <http= s://www.ietf.org/mailman/listinfo/stir>






___________= ____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.or= g/mailman/listinfo/stir


_______________________________________________
stir mailing lis= t
stir@ietf.org= https://www.ietf.org/mailman/listinfo/stir

 

= --_000_2B0F677F0B95454297753F58D4A07FA3012AEC2C55FHDP1LUMXC7V3_-- From pkyzivat@alum.mit.edu Tue Aug 20 15:18:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4AC11E814B for ; Tue, 20 Aug 2013 15:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElkppkHw7u35 for ; Tue, 20 Aug 2013 15:17:56 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 93A6511E810B for ; Tue, 20 Aug 2013 15:17:56 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id F0zx1m0071ap0As53AHukK; Tue, 20 Aug 2013 22:17:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id FAHu1m00v3ZTu2S3iAHu6J; Tue, 20 Aug 2013 22:17:54 +0000 Message-ID: <5213EB12.60605@alum.mit.edu> Date: Tue, 20 Aug 2013 18:17:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> <5213D05E.4080807@bbn.com> <5213E1AE.5090206@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377037074; bh=XtbolkcboEG3aD6Oy2DZTRgC3/JmpOC8Hrco4wZ+0gA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bES7D45Krymlm38qDcHaI5Qd1KwpBms4KoKqzDz2fuFtHrSuYuq/9q4OJ59Z0UHY7 Vp4I6rPDN6EeialwzavWV4WC9Qn8ARf5McrsbR45yBIMKc/TWZXwIRntFTEo2T2Bqj QW5ZPrzhqLv3KjiB+fDuWELYD4L7md/XlCtcVH+FxbxvqIScGWj50BLZwnZPK/yk8v K1/UhcllLhS4e3q1kMD+SZPFHxxZDse75g9Wzk0q2uMfRip6lgBVvA3Xex8JEupDzT ArfsjG3MSU3P1nHY3T1QHHlZYiKbWLNrVdntzkQhLnr5zDQxrK3Ncz4xyidNfkGCfo 9+/FBrgwAyKNQ== Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 22:18:01 -0000 ISTM that either: - it is inserted and signed by the caller, - it is determined up by somebody acting for the caller, based on authenticated identity of the caller, inserted and signed, - it is looked up by somebody in the call path, based on the authenticated calling number, inserted and signed, - or it is looked up at the receiving end by the authenticated calling number. - somebody in the call path asserts the identity, without signing it. The recipient depends on transitive trust to guarantee the validity. From the receivers perspective, either it gets an asserted calling name that it simply trusts, or else it gets a signed calling name, or else it looks up a name itself based on the calling number. In the asserted case (current IMS) if there is to be any variation in trustworthyness, then there will need to be some new mechanism to convey just that part. If it looks up the name itself, then what information is available about trustworthyness comes from its trust in the lookup service plus whatever is returned as part of the lookup. IMO we don't need to specify that. If it gets a signed calling name in the signaling, then it has information about the signer (probably a cert) to go on. Couldn't we just assume that the cert conveys (implicitly or explicitly) the level of confidence in the name? Thanks, Paul On 8/20/13 5:42 PM, Brian Rosen wrote: > No objection to carrying more, but probably we have to standardize what > more is, and that may blow up the problem. I can look into that aspect > as it applies to other domains where the same database is used. > > I do think we have to include the identity of the validation service, > but I think that would in inherent in the mechanism one way or another. > Can't have the caller or the originating SP mucking with the score, > can we? > > Brian > > > On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat > wrote: > > On 8/20/13 4:45 PM, Brian Rosen wrote: > > I don't think the IETF has the expertise, even in IRTF, to do user > interface design. We don't need to do any. If we carry a > score, the > device UI designers and the service providers can deal with it. > > > IMO a "score" (in the sense of a single number) is probably also not > the most appropriate input to presentation solutions. I expect that > we will likely have an assortment of data that can be used to assess > the validity of the name. Better to just provide all that to the UI > and let it do its thing, rather than boiling it down into a number > (and discarding useful information in the process.) > > For instance, if the name in the request is signed, then the > identity of the signer may be useful. And stuff that gets looked up > at the receiving end can have arbitrary properties. > > > We are > simply acknowledging that there is no certainty, and we're > offering to > provide the level of certainty we have. Since there are plenty of > examples of devices and services that use these kinds of scores, we > don't need to know how they work, or what any UI will do with > them. We > don't even need to offer advise on what to do. > > > For now I think less is more. In that respect I agree with you. > > Thanks, > Paul > > > > Brian > > > On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent > >> wrote: > > Hannes, > > Hi Steve, > > I think that there are various aspects to this story. > > First, there is a user interface aspect that is quite > important. > Clearly, we have noticed that already with various other > security protocols (and privacy mechanisms as well). > While the > IETF does not standardize user interfaces it would > obviously be > great if we could work with those who do this type of work. > > sounds like an IRTF task, for now. > > > Second, there is the challenge that a lot of our > technology is > pretty complex and the chances that end users > understand them is > rather unlikely (since even we have problems > understanding the > bigger picture ourselves). > > agreed! > > But what is the conclusion? Should we stop working on > security > mechanisms because others don't understand them? Should > we turn > of security (like TLS) because people get confused by > different > colours various vendors use (in their attempt to > differentiate > themselves from their competitors)? > > One conclusion is that this may not be ready for engineering. > > It certainly seems to be out of scope for this WG at this time. > > Ideally, we would like to provide a secure version only > and, in > some groups these issues actually got raised (if you > think about > the HTTP 2.0 discussions) and, as you are also aware, > there are > various companies who love insecure versions of > protocols (so > that they can build enterprise DPI boxes, aeh. content > security > devices). In this particular case it is even worse > since we have > to work around a broken legacy system and equally > insecure VoIP > deployments. There is the big transition problem. > > see comments above. > > Of course, all this does not sound like the ingredients > for an > easy protocol design. > > So, what should we do? > > 1. agree that we're going to pursue only calling # security > measures > until > this WG re-charters. > > 2. consider an IAB workshop or an IRTF group to deal with > the issue > of how > to represent individual or org ID info to users (not just VoIP) > users in a way > that does more god than harm. > > > Steve > ___________________________________________________ > > stir mailing list > stir@ietf.org > > https://www.ietf.org/mailman/____listinfo/stir > > > > > > > > > _________________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/__listinfo/stir > > > > _________________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/__listinfo/stir > > > From br@brianrosen.net Tue Aug 20 17:15:39 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB01F11E815B for ; Tue, 20 Aug 2013 17:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.499 X-Spam-Level: X-Spam-Status: No, score=-101.499 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTgrKOacTCJP for ; Tue, 20 Aug 2013 17:15:35 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3C22C11E816F for ; Tue, 20 Aug 2013 17:15:34 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so1027023pbb.13 for ; Tue, 20 Aug 2013 17:15:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X1MBOTfZuUWZBVwbEd5Gt4aSr6AiUS9ZwUhuADO9h4M=; b=Z7OYnPJFCEyV6RwNp8zKkfrR2SCOZRcERR808RfsTzhq/vEUl3JaPO3P6MnqfvEpJn PP9K0DZpPWvySYk9kJ2i1L0BBBZTK6aKBL3+WtgADVACCTg61a2vomJBd5V97mWsRfjy MzNA7KKHCAEHu4troER3Yx6RyYiUtLvi4LnoLIT/A8uVgjj5Y8mp27BPDPMNcI4uMDX3 EMT3S5tY+SGFhzIaFMgxteDBW0cv6EV7BjW2pQMJDfRKL0VWhy1pvmrXCLttGTIYFfrf j6VeRS8ZgTiV2QnAKZrBYZZR+CVDnuKv1z7Hvjhs6xbfItnh4CFX0jDhya0og9n+WfuP te/A== X-Gm-Message-State: ALoCoQl6xWWw6iOXLCEXteNQqRxoctmu+DYWbod2WCdbM7MUZlo3ffLkTBdJpMXWh0yRtR5GQq/L MIME-Version: 1.0 X-Received: by 10.68.229.2 with SMTP id sm2mr4765731pbc.68.1377044133979; Tue, 20 Aug 2013 17:15:33 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 20 Aug 2013 17:15:33 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <5213EB12.60605@alum.mit.edu> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> <5213D05E.4080807@bbn.com> <5213E1AE.5090206@alum.mit.edu> <5213EB12.60605@alum.mit.edu> Date: Tue, 20 Aug 2013 20:15:33 -0400 Message-ID: From: Brian Rosen To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b162fd7723b7e04e46a1249 Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 00:15:40 -0000 --047d7b162fd7723b7e04e46a1249 Content-Type: text/plain; charset=ISO-8859-1 Inline On Tue, Aug 20, 2013 at 6:17 PM, Paul Kyzivat wrote: > ISTM that either: > - it is inserted and signed by the caller, > Yes, possible, and workable > - it is determined up by somebody acting for the caller, > based on authenticated identity of the caller, > inserted and signed, > Yes, originating SP could do it. Could also be an enterprise if you want to separate the calling device from a proxy in the enterprise. Not likely any other SP until we get to the terminating domain > - it is looked up by somebody in the call path, > based on the authenticated calling number, inserted and signed, > Not likely, except as above > - or it is looked up at the receiving end by the authenticated > calling number. > Yes, but not as good as inserted in the orginating side. It could be the device or a service invoked by the device, or the terminating SP > - somebody in the call path asserts the identity, without > signing it. The recipient depends on transitive trust to > guarantee the validity. > I doubt this is useful > > From the receivers perspective, either it gets an asserted calling name > that it simply trusts, or else it gets a signed calling name, or else it > looks up a name itself based on the calling number. > Yeah, the first is the situation for display name today. The last is the existing alternate CNAM dips that some terminating SPs use today. > > In the asserted case (current IMS) if there is to be any variation in > trustworthyness, then there will need to be some new mechanism to convey > just that part. > Yes, that would be new work > > If it looks up the name itself, then what information is available about > trustworthyness comes from its trust in the lookup service plus whatever is > returned as part of the lookup. IMO we don't need to specify that. > Yeah, that exists today, no standardization needed. > > If it gets a signed calling name in the signaling, then it has information > about the signer (probably a cert) to go on. Couldn't we just assume that > the cert conveys (implicitly or explicitly) the level of confidence in the > name? > No. The score is based on a whole bunch of variables and varies from record to record. So it can't be in the cert. > > Thanks, > Paul > > > On 8/20/13 5:42 PM, Brian Rosen wrote: > >> No objection to carrying more, but probably we have to standardize what >> more is, and that may blow up the problem. I can look into that aspect >> as it applies to other domains where the same database is used. >> >> I do think we have to include the identity of the validation service, >> but I think that would in inherent in the mechanism one way or another. >> Can't have the caller or the originating SP mucking with the score, >> can we? >> >> Brian >> >> >> On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat > **> wrote: >> >> On 8/20/13 4:45 PM, Brian Rosen wrote: >> >> I don't think the IETF has the expertise, even in IRTF, to do user >> interface design. We don't need to do any. If we carry a >> score, the >> device UI designers and the service providers can deal with it. >> >> >> IMO a "score" (in the sense of a single number) is probably also not >> the most appropriate input to presentation solutions. I expect that >> we will likely have an assortment of data that can be used to assess >> the validity of the name. Better to just provide all that to the UI >> and let it do its thing, rather than boiling it down into a number >> (and discarding useful information in the process.) >> >> For instance, if the name in the request is signed, then the >> identity of the signer may be useful. And stuff that gets looked up >> at the receiving end can have arbitrary properties. >> >> >> We are >> simply acknowledging that there is no certainty, and we're >> offering to >> provide the level of certainty we have. Since there are plenty of >> examples of devices and services that use these kinds of scores, >> we >> don't need to know how they work, or what any UI will do with >> them. We >> don't even need to offer advise on what to do. >> >> >> For now I think less is more. In that respect I agree with you. >> >> Thanks, >> Paul >> >> >> >> Brian >> >> >> On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent > >> >> wrote: >> >> Hannes, >> >> Hi Steve, >> >> I think that there are various aspects to this story. >> >> First, there is a user interface aspect that is quite >> important. >> Clearly, we have noticed that already with various other >> security protocols (and privacy mechanisms as well). >> While the >> IETF does not standardize user interfaces it would >> obviously be >> great if we could work with those who do this type of >> work. >> >> sounds like an IRTF task, for now. >> >> >> Second, there is the challenge that a lot of our >> technology is >> pretty complex and the chances that end users >> understand them is >> rather unlikely (since even we have problems >> understanding the >> bigger picture ourselves). >> >> agreed! >> >> But what is the conclusion? Should we stop working on >> security >> mechanisms because others don't understand them? Should >> we turn >> of security (like TLS) because people get confused by >> different >> colours various vendors use (in their attempt to >> differentiate >> themselves from their competitors)? >> >> One conclusion is that this may not be ready for engineering. >> >> It certainly seems to be out of scope for this WG at this >> time. >> >> Ideally, we would like to provide a secure version only >> and, in >> some groups these issues actually got raised (if you >> think about >> the HTTP 2.0 discussions) and, as you are also aware, >> there are >> various companies who love insecure versions of >> protocols (so >> that they can build enterprise DPI boxes, aeh. content >> security >> devices). In this particular case it is even worse >> since we have >> to work around a broken legacy system and equally >> insecure VoIP >> deployments. There is the big transition problem. >> >> see comments above. >> >> Of course, all this does not sound like the ingredients >> for an >> easy protocol design. >> >> So, what should we do? >> >> 1. agree that we're going to pursue only calling # security >> measures >> until >> this WG re-charters. >> >> 2. consider an IAB workshop or an IRTF group to deal with >> the issue >> of how >> to represent individual or org ID info to users (not just >> VoIP) >> users in a way >> that does more god than harm. >> >> >> Steve >> ______________________________**_____________________ >> >> stir mailing list >> stir@ietf.org > > >> https://www.ietf.org/mailman/_**___listinfo/stir >> >> > >> >> >> >> >> >> >> >> >> >> >> ______________________________**___________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/stir >> >> > >> >> >> ______________________________**___________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/stir >> >> > >> >> >> > --047d7b162fd7723b7e04e46a1249 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline


On Tue, Aug 20, 2013 at 6:17 PM, Paul Kyzivat <pkyzivat@= alum.mit.edu> wrote:
ISTM that either:
- it is inserted and signed by the caller,
Yes, possib= le, and workable
=A0
- it is determined up by somebody acting for the caller,
=A0 based on authenticated identity of the caller,
=A0 inserted and signed,
Yes, originating SP could do = it. =A0Could also be an enterprise if you want to separate the calling devi= ce from a proxy in the enterprise. =A0Not likely any other SP until we get = to the terminating domain
=A0
- it is looked up by somebody in the call path,
=A0 based on the authenticated calling number, inserted and signed,
Not likely, except as above
=A0
- or it is looked up at the receiving end by the authenticated
=A0 calling number.
Yes, but not as good as inserted i= n the orginating side. =A0It could be the device or a service invoked by th= e device, or the terminating SP
=A0
- somebody in the call path asserts the identity, without
=A0 signing it. The recipient depends on transitive trust to
=A0 guarantee the validity.
I doubt this is useful=A0<= /div>

>From the receivers perspective, either it gets an asserted calling name tha= t it simply trusts, or else it gets a signed calling name, or else it looks= up a name itself based on the calling number.
Yeah, t= he first is the situation for display name today. =A0The last is the existi= ng alternate CNAM dips that some terminating SPs use today.
=A0

In the asserted case (current IMS) if there is to be any variation in trust= worthyness, then there will need to be some new mechanism to convey just th= at part.
Yes, that would be new work
=A0

If it looks up the name itself, then what information is available about tr= ustworthyness comes from its trust in the lookup service plus whatever is r= eturned as part of the lookup. IMO we don't need to specify that.
Yeah, that exists today, no standardization needed.
=
=A0

If it gets a signed calling name in the signaling, then it has information = about the signer (probably a cert) to go on. Couldn't we just assume th= at the cert conveys (implicitly or explicitly) the level of confidence in t= he name?
No. =A0The score is based on a whole bunch of variables a= nd varies from record to record. =A0So it can't be in the cert.=A0
=A0

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 8/20/13 5:42 PM, Brian Rosen wrote:
No objection to carrying more, but probably we have to standardize what
more is, and that may blow up the problem. =A0I can look into that aspect as it applies to other domains where the same database is used.

I do think we have to include the identity of the validation service,
but I think that would in inherent in the mechanism one way or another.
=A0 Can't have the caller or the originating SP mucking with the score,=
can we?

Brian


On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
<= div class=3D"h5"> <mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 On 8/20/13 4:45 PM, Brian Rosen wrote:

=A0 =A0 =A0 =A0 I don't think the IETF has the expertise, even in IRTF,= to do user
=A0 =A0 =A0 =A0 interface design. =A0We don't need to do any. =A0If we = carry a
=A0 =A0 =A0 =A0 score, the
=A0 =A0 =A0 =A0 device UI designers and the service providers can deal with= it.


=A0 =A0 IMO a "score" (in the sense of a single number) is probab= ly also not
=A0 =A0 the most appropriate input to presentation solutions. I expect that=
=A0 =A0 we will likely have an assortment of data that can be used to asses= s
=A0 =A0 the validity of the name. Better to just provide all that to the UI=
=A0 =A0 and let it do its thing, rather than boiling it down into a number<= br> =A0 =A0 (and discarding useful information in the process.)

=A0 =A0 For instance, if the name in the request is signed, then the
=A0 =A0 identity of the signer may be useful. And stuff that gets looked up=
=A0 =A0 at the receiving end can have arbitrary properties.


=A0 =A0 =A0 =A0 We are
=A0 =A0 =A0 =A0 simply acknowledging that there is no certainty, and we'= ;re
=A0 =A0 =A0 =A0 offering to
=A0 =A0 =A0 =A0 provide the level of certainty we have. =A0Since there are = plenty of
=A0 =A0 =A0 =A0 examples of devices and services that use these kinds of sc= ores, we
=A0 =A0 =A0 =A0 don't need to know how they work, or what any UI will d= o with
=A0 =A0 =A0 =A0 them. =A0We
=A0 =A0 =A0 =A0 don't even need to offer advise on what to do.


=A0 =A0 For now I think less is more. In that respect I agree with you.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul



=A0 =A0 =A0 =A0 Brian


=A0 =A0 =A0 =A0 On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent <kent@bbn.com
=A0 =A0 =A0 =A0 <mailto:kent@bbn.com>
=A0 =A0 =A0 =A0 <mailto:kent@bbn.com <mailto:kent@bbn.com>>> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0Hannes,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi Steve,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I think that there are various aspects t= o this story.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0First, there is a user interface aspect = that is quite
=A0 =A0 =A0 =A0 important.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Clearly, we have noticed that already wi= th various other
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0security protocols (and privacy mechanis= ms as well).
=A0 =A0 =A0 =A0 While the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IETF does not standardize user interface= s it would
=A0 =A0 =A0 =A0 obviously be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0great if we could work with those who do= this type of work.

=A0 =A0 =A0 =A0 =A0 =A0 =A0sounds like an IRTF task, for now.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Second, there is the challenge that a lo= t of our
=A0 =A0 =A0 =A0 technology is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pretty complex and the chances that end = users
=A0 =A0 =A0 =A0 understand them is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rather unlikely (since even we have prob= lems
=A0 =A0 =A0 =A0 understanding the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bigger picture ourselves).

=A0 =A0 =A0 =A0 =A0 =A0 =A0agreed!

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0But what is the conclusion? Should we st= op working on
=A0 =A0 =A0 =A0 security
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mechanisms because others don't unde= rstand them? Should
=A0 =A0 =A0 =A0 we turn
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of security (like TLS) because people ge= t confused by
=A0 =A0 =A0 =A0 different
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0colours various vendors use (in their at= tempt to
=A0 =A0 =A0 =A0 differentiate
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0themselves from their competitors)?

=A0 =A0 =A0 =A0 =A0 =A0 =A0One conclusion is that this may not be ready for= engineering.

=A0 =A0 =A0 =A0 =A0 =A0 =A0It certainly seems to be out of scope for this W= G at this time.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ideally, we would like to provide a secu= re version only
=A0 =A0 =A0 =A0 and, in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some groups these issues actually got ra= ised (if you
=A0 =A0 =A0 =A0 think about
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the HTTP 2.0 discussions) and, as you ar= e also aware,
=A0 =A0 =A0 =A0 there are
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0various companies who love insecure vers= ions of
=A0 =A0 =A0 =A0 protocols (so
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that they can build enterprise DPI boxes= , aeh. content
=A0 =A0 =A0 =A0 security
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0devices). In this particular case it is = even worse
=A0 =A0 =A0 =A0 since we have
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to work around a broken legacy system an= d equally
=A0 =A0 =A0 =A0 insecure VoIP
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0deployments. There is the big transition= problem.

=A0 =A0 =A0 =A0 =A0 =A0 =A0see comments above.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Of course, all this does not sound like = the ingredients
=A0 =A0 =A0 =A0 for an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0easy protocol design.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So, what should we do?

=A0 =A0 =A0 =A0 =A0 =A0 =A01. agree that we're going to pursue only cal= ling # security
=A0 =A0 =A0 =A0 measures
=A0 =A0 =A0 =A0 =A0 =A0 =A0until
=A0 =A0 =A0 =A0 =A0 =A0 =A0this WG re-charters.

=A0 =A0 =A0 =A0 =A0 =A0 =A02. consider an IAB workshop or an IRTF group to = deal with
=A0 =A0 =A0 =A0 the issue
=A0 =A0 =A0 =A0 =A0 =A0 =A0of how
=A0 =A0 =A0 =A0 =A0 =A0 =A0to represent individual or org ID info to users = (not just VoIP)
=A0 =A0 =A0 =A0 =A0 =A0 =A0users in a way
=A0 =A0 =A0 =A0 =A0 =A0 =A0that does more god than harm.


=A0 =A0 =A0 =A0 =A0 =A0 =A0Steve
=A0 =A0 =A0 =A0 =A0 =A0 =A0_________________________________________= __________

=A0 =A0 =A0 =A0 =A0 =A0 =A0stir mailing list
=A0 =A0 =A0 =A0 stir@iet= f.org <mailto:sti= r@ietf.org> <mailto:stir@ietf.org
=A0 =A0 =A0 =A0 <mailto:stir@ietf.org>>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/____listinfo/stir=
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/stir= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__listin= fo/stir
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/stir>= >






=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 stir mailing list
=A0 =A0 =A0 =A0 stir@iet= f.org <mailto:sti= r@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/stir
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/stir>=


=A0 =A0 _________________________________________________
=A0 =A0 stir mailing list
=A0 =A0 stir@ietf.org <mailto:stir@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/stir
=A0 =A0 <https://www.ietf.org/mailman/listinfo/stir>




--047d7b162fd7723b7e04e46a1249-- From richard@shockey.us Tue Aug 20 17:46:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F6A11E834D for ; Tue, 20 Aug 2013 17:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOYcZxOmgAJR for ; Tue, 20 Aug 2013 17:46:53 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id CB59211E834C for ; Tue, 20 Aug 2013 17:46:52 -0700 (PDT) Received: (qmail 7616 invoked by uid 0); 21 Aug 2013 00:46:27 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.mail.unifiedlayer.com with SMTP; 21 Aug 2013 00:46:27 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=eiI5erWCHwmabkDYaqJEkXypiUoLGTrG9Gv5h0SJ1wk=; b=Awb6suSu2bXMyw/HVLZ8gmdlKqdkIT1MtCYRGl6+CoxZF7Cvr8GxH8PvY3MTSjvQO4Ct05KSM+uje9sDBTBe8qz9IThnl8imGWHg2nGmung7Z1SGMc/zqe6S4ACfTZs+; Received: from [71.114.100.16] (port=57120 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VBwZ9-0006Th-Gl; Tue, 20 Aug 2013 18:46:27 -0600 From: "Richard Shockey" To: "'Paul Kyzivat'" , References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> <5213D05E.4080807@bbn.com> <5213E1AE.509020 6@alum.mit.edu> In-Reply-To: <5213E1AE.5090206@alum.mit.edu> Date: Tue, 20 Aug 2013 20:46:25 -0400 Message-ID: <01b801ce9e07$de274bc0$9a75e340$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQG6c5U9AiUaR1cBz8RHYQFaT0AzAeFsewQCtGDn4ALqgx/SAnzolLQChuP8PAHuOBPCAVc6t7YBb+gEuAFq48RpAVA9HFgBmHbhrgJdUlAAAxQYut8BuHBeopenlZbw X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 00:46:58 -0000 Well we are there right now. http://datatracker.ietf.org/wg/repute/charter/ Though not necessarily applicable to the STIR problem statement we know we are dealing with this issue in multiple areas. A numeric value to a level of reputation trust could be easily grasped by consumers. They certainly know what their credit rating score is when going for a car loan. The issue is some form of data object presented to the SIP UA that presents it to the consumer. We are not going there. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, August 20, 2013 5:38 PM To: stir@ietf.org Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) On 8/20/13 4:45 PM, Brian Rosen wrote: > I don't think the IETF has the expertise, even in IRTF, to do user > interface design. We don't need to do any. If we carry a score, the > device UI designers and the service providers can deal with it. IMO a "score" (in the sense of a single number) is probably also not the most appropriate input to presentation solutions. I expect that we will likely have an assortment of data that can be used to assess the validity of the name. Better to just provide all that to the UI and let it do its thing, rather than boiling it down into a number (and discarding useful information in the process.) For instance, if the name in the request is signed, then the identity of the signer may be useful. And stuff that gets looked up at the receiving end can have arbitrary properties. > We are > simply acknowledging that there is no certainty, and we're offering to > provide the level of certainty we have. Since there are plenty of > examples of devices and services that use these kinds of scores, we > don't need to know how they work, or what any UI will do with them. > We don't even need to offer advise on what to do. For now I think less is more. In that respect I agree with you. Thanks, Paul > Brian > > > On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent > wrote: > > Hannes, > > Hi Steve, > > I think that there are various aspects to this story. > > First, there is a user interface aspect that is quite important. > Clearly, we have noticed that already with various other > security protocols (and privacy mechanisms as well). While the > IETF does not standardize user interfaces it would obviously be > great if we could work with those who do this type of work. > > sounds like an IRTF task, for now. > > > Second, there is the challenge that a lot of our technology is > pretty complex and the chances that end users understand them is > rather unlikely (since even we have problems understanding the > bigger picture ourselves). > > agreed! > > But what is the conclusion? Should we stop working on security > mechanisms because others don't understand them? Should we turn > of security (like TLS) because people get confused by different > colours various vendors use (in their attempt to differentiate > themselves from their competitors)? > > One conclusion is that this may not be ready for engineering. > > It certainly seems to be out of scope for this WG at this time. > > Ideally, we would like to provide a secure version only and, in > some groups these issues actually got raised (if you think about > the HTTP 2.0 discussions) and, as you are also aware, there are > various companies who love insecure versions of protocols (so > that they can build enterprise DPI boxes, aeh. content security > devices). In this particular case it is even worse since we have > to work around a broken legacy system and equally insecure VoIP > deployments. There is the big transition problem. > > see comments above. > > Of course, all this does not sound like the ingredients for an > easy protocol design. > > So, what should we do? > > 1. agree that we're going to pursue only calling # security measures > until > this WG re-charters. > > 2. consider an IAB workshop or an IRTF group to deal with the issue > of how > to represent individual or org ID info to users (not just VoIP) > users in a way > that does more god than harm. > > > Steve > _________________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/__listinfo/stir > > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Wed Aug 21 12:07:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2114011E811E; Wed, 21 Aug 2013 12:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMpuxIGZl91G; Wed, 21 Aug 2013 12:07:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF5A21F9E68; Wed, 21 Aug 2013 12:07:40 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7LJ7RLA024392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 12:07:30 -0700 Message-ID: <52150FD6.8010306@dcrocker.net> Date: Wed, 21 Aug 2013 12:07:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ietf@ietf.org References: <20130821175202.24713.10458.idtracker@ietfa.amsl.com> In-Reply-To: <20130821175202.24713.10458.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Aug 2013 12:07:31 -0700 (PDT) Cc: stir WG , The IESG Subject: Re: [stir] WG Review: Secure Telephone Identity Revisited (stir) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:07:47 -0000 The following mostly are points that I raised within the group's mailing list discussion, during charter development. In my view, they have not yet been adequately resolved: On 8/21/2013 10:52 AM, The IESG wrote: > Please send your comments to the IESG mailing list (iesg > at ietf.org) by 2013-08-28. ... > The STIR working group will specify Internet-based mechanisms that allow > verification of the calling party's authorization to use a particular > telephone number for an incoming call. "use a particular telephone number for an incoming call" has no obvious and unambiguous technical meaning. In fact, it seems to imply the meaning of "authorization to call a particular number". However of course that's not the intended meaning. Since this is the only text in this paragraph that says what the working group will /do/ it should make its statement with clarity and technical substance. That is, the charter needs to use a precise term for specifying the specific role of the number of interest. In earlier drafts, "caller id" was used. The next sentence uses "source telephone number". Perhaps that is acceptable. > Since it has become fairly easy > to present an incorrect source telephone number, a growing set of > problems have emerged over the last decade. As with email, the claimed > source identity of a SIP request is not verified, permitting unauthorized As a matter of form, I'll note the SIP's community's use of "identity" is what is called "identifier" in the identity community. ... > As its priority mechanism work item, the working group will specify a SIP Reference to work priority is only meaningful in the face of a list of tasks that will be considered simultaneously and what it means to give priority to one over another. Based on the lengthy mailing list discussion of in-band vs. out-of-band, it appears that the current charter is actually intended to support simultaneous work on alternative mechanisms, rather than pursuing them sequentially. This should be made explicit. If the requirement is to work on them sequentially, then state that. If the intent is to work on both approaches simultaneously, then say that. ... > In addition to its priority mechanism work item, the working group will > consider a mechanism for verification of the originator during session > establishment in an environment with one or more non-SIP hops, most > likely requiring an out-of-band authorization mechanism. However, the > in-band and the out-of-band mechanisms should share as much in common as > possible, especially the credentials. The in-band mechanism must be sent > to the IESG for approval and publication prior to the out-of-band > mechanism. "in-band and the out-of-band mechanisms should share as much in common as possible" This is the essential text that mandates working on both approaches simultaneously and makes the earliet assertion about priority moot. (Note how far down in the charter this is buried, yet how fundamental a requirement is establishes.) ... > Input to working group discussions shall include: > That's a lengthy list of documents. Why has it left out other documents discussed during charter development and clearly of continuing interest to the effort, namely: A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER) draft-kaplan-stir-cider-00 An Identity Key-based and Effective Signature for Origin-Unknown Types draft-kaplan-stir-ikes-out-00 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kent@bbn.com Wed Aug 21 12:27:00 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FE721F9FD5 for ; Wed, 21 Aug 2013 12:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk78Jdks+pO3 for ; Wed, 21 Aug 2013 12:26:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 77CBF21F9FC6 for ; Wed, 21 Aug 2013 12:26:54 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51748) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VCE3Q-0007RJ-GB; Wed, 21 Aug 2013 15:26:52 -0400 Message-ID: <5215147C.9050500@bbn.com> Date: Wed, 21 Aug 2013 15:26:52 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <9E14519D-B820-47E1-8AD5-A8AE52A46814@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3BFF@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012ADB3CF8@FHDP1LUMXC7V31.us.one.verizon.com> <521262E4.3070109@bbn.com> <5213AB0A.3090603@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC2B14E@EX2K10MB1.corp.yaanatech.com> <5213C083.90309@bbn.com> <5213C3F8.3040200@gmx.net> <5213D05E.4080807@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:27:00 -0000 Brian, As of now, the charter expressly refers to caller identity that we're working to secure as the caller's phone number (with some broad interpretation of that phrase). If you want a caller name to be in scope, you should ask for a change to the charter text. Steve From hadriel.kaplan@oracle.com Wed Aug 21 12:34:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C796321F9F6C; Wed, 21 Aug 2013 12:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsiQ4IlLAowa; Wed, 21 Aug 2013 12:34:41 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CEADB21F9F5E; Wed, 21 Aug 2013 12:34:40 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7LJYcwm015410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Aug 2013 19:34:39 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LJYc2E007930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 19:34:38 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LJYcrJ000955; Wed, 21 Aug 2013 19:34:38 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Aug 2013 12:34:37 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 21 Aug 2013 15:34:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130821175202.24713.10458.idtracker@ietfa.amsl.com> <52150FD6.8010306@dcrocker.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: stir WG , The IESG , ietf Subject: Re: [stir] WG Review: Secure Telephone Identity Revisited (stir) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:34:47 -0000 On Aug 21, 2013, at 3:18 PM, Christopher Morrow = wrote: >> "use a particular telephone number for an incoming call" has no = obvious and >=20 > it'd actually be kind of nice if the focus was NOT on the (us) > 10-digit "number", but instead on the 'identity' making the call. > There's a real chance to move beyond the '10-digit number' and to some > stronger, wider, richer sense of 'identity'... we should take that > opportunity and run with it. To be clear, the focus is not on a 10-digit number nor numbers for any = specific country-code. It's for the global E.164 number space. With regard to other 'identities', if you mean = non-telephone-number-based SIP user@domain type names, the IETF has a PS = RFC for that: RFC 4474. Its adoption rate requires double = floating-point precision to detect it not being 0%. ;) This proposed-WG is due to real-world issues in deployments using = telephone numbers, so that's been our focus scope to "fix". As it = happens, both of the proposed STIR solutions so far have in fact = addressed more than just telephone numbers, including the user@domain = type. I've been told so long as we get it "for free" so-to-speak, we = can address them as well in our deliverables - we just need to focus on = telephone numbers since that's the problem that needs fixin'. > no... focus on 'telephone number' is broken. Hell, it's not even > what's used in the phone system anyway... not really. Ummm... ok, what is it you think is used in the phone system really? Or = what better word/term would you use to label what's used in the phone = system? -hadriel From fluffy@cisco.com Thu Aug 22 07:53:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0471E11E81BB for ; Thu, 22 Aug 2013 07:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1nGLM72pjve for ; Thu, 22 Aug 2013 07:53:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 775E711E80FB for ; Thu, 22 Aug 2013 07:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=926; q=dns/txt; s=iport; t=1377183219; x=1378392819; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aaZAkzHO/KW1HqNt87Sm0gxrEY8LOCtoMHk4P+vKOGw=; b=B96kONXVGmsEdcY8dn7kf5bJcdaxz5tBoAq4dtGrgfcwU+Nlpe6hW5MF UeK/KlLzAZ2+N0MfUX1i3Hv+E7VuHu0G5zCM6ItxwthxF2ChU8+BxpfB7 mmxhKhn3nzSfLEBmwVeuaEZ84I2TEYSwwkJSFRSPfn6yYHJ77I4HSPJky Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEGAF8lFlKtJXG9/2dsb2JhbABEFoMFgQaCVL00gRwWbQeCJAEBAQMBOkQLAgEqCQsQMiUCBBMIiAIGrxmPFYEgOIMbewOpQIMfgis X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="scan'208";a="250291152" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 22 Aug 2013 14:53:39 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7MErc8h021802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 22 Aug 2013 14:53:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.221]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 09:53:38 -0500 From: "Cullen Jennings (fluffy)" To: "stir@ietf.org" Thread-Topic: CNAM Thread-Index: AQHOn0diOOouRNyojEaV+igPx31u2g== Date: Thu, 22 Aug 2013 14:53:37 +0000 Message-ID: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> In-Reply-To: <015101ce988e$27aa1900$76fe4b00$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <0BFEBD9F8765684CABFAB669324EEC15@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [stir] CNAM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 14:53:45 -0000 On Aug 13, 2013, at 7:32 PM, Richard Shockey wrote: > What is the successor to CNAM?=20 The thing that has already replaced CNAM for me is my personal address book= on my phone and/or linkedin. When I get a call on my phone, the caller ID = is looked up in the address book and the name that I assigned in my address= book gets display. I like that. Some newer stuff will use my social networ= ks to grab me the relevant context for that phone number.=20 So to be clear, I view the CNAM thing, which is about human readable names = that are not unique, should be kept very separate from the unique identifie= rs (phone numbers in this context). The problem of how the CA can verify th= e human readable name seems not only hard to solve, but also undesirable to= bother solving. Other attributes, like "this organization is a US register= ed bank" might be easier to deal with.=20 From fluffy@cisco.com Thu Aug 22 07:53:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2D211E80FB for ; Thu, 22 Aug 2013 07:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8xTZ7Kvo+yK for ; Thu, 22 Aug 2013 07:53:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6791E11E80F6 for ; Thu, 22 Aug 2013 07:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1444; q=dns/txt; s=iport; t=1377183219; x=1378392819; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HiwLJt7cs+UZ1ZZjLeFczQDh4h+IZrZJVQH0fDJ/cSo=; b=N0GNBfPlAnVCXlMQOw8+0C46A29kh9lXeKA61DJFhmLMD7sy3wUzF8oh a6jVfP7J2H0K7c2yaqc/RxefUgUe2aqTUgo+9p+40sTHeitOM8nTrdZR8 30Z+42x5meaIkZZgbXuXHS+CihuKR+mpwzjYyeiDqFQHnhFSRde2QsF3L A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0FAOUkFlKtJXHB/2dsb2JhbABEFoMFNVHACIEcFm0HgiQBAQEDAToPHRgLAgEIIgkLEDIlAgQTCIgCBgyvDI8VgR4COIMbewOpQIFkgTuCKw X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="scan'208";a="250473661" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 22 Aug 2013 14:53:39 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7MErcCb025530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 22 Aug 2013 14:53:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.221]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 09:53:38 -0500 From: "Cullen Jennings (fluffy)" To: "stir@ietf.org" Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: AQHOn0dioxA3AQnviEqr8HPmC8HVPw== Date: Thu, 22 Aug 2013 14:53:38 +0000 Message-ID: References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> In-Reply-To: <012801ce9cff$491305a0$db3910e0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 14:53:45 -0000 On Aug 19, 2013, at 11:12 AM, Richard Shockey wrote: > Remember those databases are already in existence now. Phone companies an= d > others have the data. A binding of number to "preferred display name" > determined by the number holder as part of the service should be doable. I have not checked into the regulation but as far as I can tell, in Canada = end consumers can request whatever they want to be put in this database as = long as it is not profane (and reading the white pages, there is some prett= y funny stuff ). I have not seen what happens if I request "HSBC Bank" but = "Flu Ffy" seems to be OK.=20 And this does not even get in to the www.stamford.edu problem ( This organi= zation advertises all over Thailand - check out my photo at http://www.flic= kr.com/photos/cullenfluffyjennings/9570844196/ I particularly love their = truth in advertising tag line of "The Difference is Real" ).=20 Given we don't really know how to solve this problem, and we are dealing wi= th the internet where in some countries "Bank of America" may not be the sa= me organization it is in the US and they don't care about US trademark laws= , I think we will simply fail on human readable names and instead need to f= ocus on the unique verifiable identifiers and allow other mechanisms to map= the unique identifiers to things that make sense to the human user in that= users context.=20 From fluffy@cisco.com Thu Aug 22 07:53:59 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A0D21F8C65; Thu, 22 Aug 2013 07:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRnuKol527+9; Thu, 22 Aug 2013 07:53:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC4911E814C; Thu, 22 Aug 2013 07:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8522; q=dns/txt; s=iport; t=1377183233; x=1378392833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=f+RmQwZtHNuntTRrbzz1nY1goo82KHanVN/FKGv9lwA=; b=eoR3I9OM/LNm5eQQsHcvB5EO1dAkUDzOicWMWYF4DLHzTcXPh/5xVo+c /TYNbnyUvGo+J2+Emn3HZAM5tNqnESDCMH4xApEidecD3lPMip+8DWRJl mOjdNmam8Qf7v2szfU8iGteoCsa1MiT2RRLzWQjwgAkiYWsgeKAPXtpZf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0FANwlFlKtJXG//2dsb2JhbABOAwmDBTVRwAiBHBZtB4IkAQEBAwEBAQEaHR8VCwULAgEIIgISECcLJQIEDgMCCAESh28GDK8PjxgBBAcDBoEGAjEHgxt7A5NMQZUzgx9AgSkCBxcCBBw X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="scan'208";a="250458678" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 22 Aug 2013 14:53:39 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7MErdno007150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 14:53:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.221]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 09:53:38 -0500 From: "Cullen Jennings (fluffy)" To: "ietf@ietf.org" Thread-Topic: WG Review: Secure Telephone Identity Revisited (stir) Thread-Index: AQHOn0diLpFeqm1CkkWDY3sxz5Amcg== Date: Thu, 22 Aug 2013 14:53:38 +0000 Message-ID: References: <20130821175202.24713.10458.idtracker@ietfa.amsl.com> In-Reply-To: <20130821175202.24713.10458.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: stir WG Subject: Re: [stir] WG Review: Secure Telephone Identity Revisited (stir) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 14:53:59 -0000 This looks reasonable to me and given how much effort it has taken to get a= greement on theses words, I am not keen on any of the material changes I ha= ve seen proposed. On Aug 21, 2013, at 11:52 AM, The IESG wrote: > A new IETF working group has been proposed in the Real-time Applications > and Infrastructure Area. The IESG has not made any determination yet. The > following draft charter was submitted, and is provided for informational > purposes only. Please send your comments to the IESG mailing list (iesg > at ietf.org) by 2013-08-28. >=20 > Secure Telephone Identity Revisited (stir) > ------------------------------------------------ > Current Status: Proposed WG >=20 > Chairs: > TBD >=20 > Assigned Area Director: > Richard Barnes >=20 > Mailing list > Address: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir > Archive: http://www.ietf.org/mail-archive/web/stir/ >=20 > Charter: >=20 > The STIR working group will specify Internet-based mechanisms that allow= =20 > verification of the calling party's authorization to use a particular=20 > telephone number for an incoming call. Since it has become fairly easy= =20 > to present an incorrect source telephone number, a growing set of=20 > problems have emerged over the last decade. As with email, the claimed=20 > source identity of a SIP request is not verified, permitting unauthorized >=20 > use of the source identity as part of deceptive and coercive activities,= =20 > such as robocalling (bulk unsolicited commercial communications), vishing >=20 > (voicemail hacking, and impersonating banks) and swatting (impersonating= =20 > callers to emergency services to stimulate unwarranted large scale law=20 > enforcement deployments). In addition, use of an incorrect source=20 > telephone number facilitates wire fraud or can lead to a return call at=20 > premium rates. =20 >=20 > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not seen > any appreciable deployment. Several factors contributed to this lack of > success, including: failure of the problem to be seen as critical at the > time; lack of any technical means of producing a proof of authorization > to > use telephone numbers; misalignment of the mechanisms proposed by RFC > 4474 > with the complex deployment environment that has emerged for SIP; lack of > end-to-end SIP session establishment; and inherent operational problems > with a transitive trust model. To make deployment of this solution more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. >=20 > As its priority mechanism work item, the working group will specify a SIP > header-based mechanism for verification that the originator of a SIP=20 > session is authorized to use the claimed source telephone number, where=20 > the session is established with SIP end to end. This is called an > in-band=20 > mechanism. The mechanism will use a canonical telephone number=20 > representation specified by the working group, including any mappings > that=20 > might be needed between the SIP header fields and the canonical telephone >=20 > number representation. The working group will consider choices for=20 > protecting identity information and credentials used. This protection=20 > will likely be based on a digital signature mechanism that covers a set=20 > of information in the SIP header fields, and verification will employ a=20 > credential that contains the public key that is associated with the one=20 > or more telephone numbers. Credentials used with this mechanism will be= =20 > derived from existing telephone number assignment and delegation models.= =20 >=20 > That is, when a telephone number or range of telephone numbers is=20 > delegated to an entity, relevant credentials will be generated (or=20 > modified) to reflect such delegation. The mechanism must allow a=20 > telephone number holder to further delegate and revoke use of a telephone >=20 > number without compromising the global delegation scheme. >=20 > In addition to its priority mechanism work item, the working group will > consider a mechanism for verification of the originator during session > establishment in an environment with one or more non-SIP hops, most > likely requiring an out-of-band authorization mechanism. However, the > in-band and the out-of-band mechanisms should share as much in common as > possible, especially the credentials. The in-band mechanism must be sent > to the IESG for approval and publication prior to the out-of-band > mechanism. >=20 > Expansion of the authorization mechanism to identities using the > user@domain form is out of scope. The work of this group is limited to > developing a solution for telephone numbers. >=20 > The working group will coordinate with the Security Area on credential > management. >=20 > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. >=20 > The working group welcomes input from potential implementors or operators >=20 > of technologies developed by this working group. For example, national=20 > numbering authorities might consider acting as credential authorities for >=20 > telephone numbers within their purview. >=20 > It is important to note that while the main focus of this working group > is telephone numbers, the STIR working group will not develop any > mechanisms that require changes to circuit-switched technologies. >=20 > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. In order to > support anonymity, the working group will provide a solution in which the > called party receives an indication that the source telephone number is > unavailable. This working group, to the extent feasible, will specify > privacy-friendly mechanisms that do not reveal any more information to > user agents or third parties than a call that does not make use of secure > telephone identification mechanisms. >=20 > Input to working group discussions shall include: >=20 > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] >=20 > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] >=20 > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] >=20 > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] >=20 > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] >=20 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situations that motivate work on secure telephone identity >=20 > - A threat model for the secure telephone identity mechanisms >=20 > - A privacy analysis of the secure telephone identity mechanisms >=20 > - A document describing the SIP in-band mechanism for telephone > number-based identities during call setup >=20 > - A document describing the credentials required to support > telephone number identity authentication >=20 > - A document describing the out-of-band mechanism for telephone > number-based identities during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit threat model for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Apr 2014 Submit Privacy analysis for Informational > Jun 2014 Submit out-of-band mechanism for Proposed Standard >=20 From rlb@ipv.sx Thu Aug 22 11:46:52 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F8A11E812D for ; Thu, 22 Aug 2013 11:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxQmaSZVW9UD for ; Thu, 22 Aug 2013 11:46:47 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFB211E815C for ; Thu, 22 Aug 2013 11:46:35 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so4303800oag.30 for ; Thu, 22 Aug 2013 11:46:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/TuIXDnMHXbbXdfFZ3BF171pfO3lQoHJXal1e4uTanI=; b=IyEZmEgjZpQW1XL2JX9ujFy0pVzQ4JtnbvVyZZNHXjf+FhKmPEt5HjrFByP936mmVg loH70kYooc/QpkI4/SwCkPvI41c0sWp5JE/jcPcZBhm6KriZzGOdFmJX0M+BU20ze8U4 +ggQD6LrYhJ1Ks6+A/aSMZbEwLDTARFvq1ndKtg+t70GYyJS3C0r8r4tRLvSgPjOyQk5 ZjTGY20zCAxOVbOI/OEH6+fUgcD+jbp1cp2gXFdWrk8wFC/oxvVs/DxmkaEvWahFGWiF LO5qluR7zu1sQ2LD7r6NGQunMr3hzcuGeNs7wSAwTkGPIoYjsXej48FfroCc3uZZ/YXy +o6w== X-Gm-Message-State: ALoCoQmQtcA7Px6soAGfzLG2g5nxryLgl6aCTeWy8yynytO9oLBIm1VFx7uhHTowGu/P3jDQrRMF MIME-Version: 1.0 X-Received: by 10.182.199.74 with SMTP id ji10mr15933772obc.69.1377197194735; Thu, 22 Aug 2013 11:46:34 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Thu, 22 Aug 2013 11:46:34 -0700 (PDT) X-Originating-IP: [192.1.51.95] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> Date: Thu, 22 Aug 2013 14:46:34 -0400 Message-ID: From: Richard Barnes To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=e89a8ff1c024940a6704e48db554 Cc: "stir@ietf.org" Subject: Re: [stir] CNAM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 18:46:52 -0000 --e89a8ff1c024940a6704e48db554 Content-Type: text/plain; charset=ISO-8859-1 More generally, if a called party can authenticate a TN, then they can use that as a trusted key to look up associated information (names, attributes) from other services. In Cullen's example, that service is a local one (the phone address book), but in principle you could also have network-based services. So focusing on the TN authentication problem first seems entirely sensible. --Richard On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennings (fluffy) wrote: > > On Aug 13, 2013, at 7:32 PM, Richard Shockey wrote: > > > What is the successor to CNAM? > > The thing that has already replaced CNAM for me is my personal address > book on my phone and/or linkedin. When I get a call on my phone, the caller > ID is looked up in the address book and the name that I assigned in my > address book gets display. I like that. Some newer stuff will use my social > networks to grab me the relevant context for that phone number. > > So to be clear, I view the CNAM thing, which is about human readable names > that are not unique, should be kept very separate from the unique > identifiers (phone numbers in this context). The problem of how the CA can > verify the human readable name seems not only hard to solve, but also > undesirable to bother solving. Other attributes, like "this organization is > a US registered bank" might be easier to deal with. > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --e89a8ff1c024940a6704e48db554 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<hat type=3D"none"/>

Mo= re generally, if a called party can authenticate a TN, then they can use th= at as a trusted key to look up associated information (names, attributes) f= rom other services. =A0In Cullen's example, that service is a local one= (the phone address book), but in principle you could also have network-bas= ed services. =A0So focusing on the TN authentication problem first seems en= tirely sensible.

--Richard

On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennin= gs (fluffy) <fluffy@cisco.com> wrote:

On Aug 13, 2013, at 7:32 PM, Richard Shockey <richard@shockey.us> wrote:

> What is the successor to CNAM?

The thing that has already replaced CNAM for me is my personal address book= on my phone and/or linkedin. When I get a call on my phone, the caller ID = is looked up in the address book and the name that I assigned in my address= book gets display. I like that. Some newer stuff will use my social networ= ks to grab me the relevant context for that phone number.

So to be clear, I view the CNAM thing, which is about human readable names = that are not unique, should be kept very separate from the unique identifie= rs (phone numbers in this context). The problem of how the CA can verify th= e human readable name seems not only hard to solve, but also undesirable to= bother solving. Other attributes, like "this organization is a US reg= istered bank" might be easier to deal with.


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--e89a8ff1c024940a6704e48db554-- From dhc@dcrocker.net Thu Aug 22 11:49:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC5211E80F8 for ; Thu, 22 Aug 2013 11:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEZSy-4ZiOMX for ; Thu, 22 Aug 2013 11:49:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0F611E81EB for ; Thu, 22 Aug 2013 11:49:53 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7MInnDd017950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Aug 2013 11:49:52 -0700 Message-ID: <52165D32.8060400@dcrocker.net> Date: Thu, 22 Aug 2013 11:49:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Richard Barnes References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> <3EBB523E-5A34-455F-8709-E2F72442B00E@standardstrack.com> <520160CD.5000306@bbn.com> <24BD7BAF-A166-401B-BF01-AD507F31D24B@standardstrack.com> <520A646C.9030909@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC27CEE@EX2K10MB1.corp.yaanatech.com> <00be01ce9850$fdc2a2c0$f947e840$@shockey.us> <015101ce988e$27aa1900$76fe4b00$@shockey.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 22 Aug 2013 11:49:53 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] CNAM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 18:49:58 -0000 On 8/22/2013 11:46 AM, Richard Barnes wrote: > if a called party can authenticate a TN, then they can use that as a > trusted key to look up associated information (names, attributes) from > other services. This is one of the better and more concise descriptions of the value proposition for this type of mechanism that I've seen (after more than 10 years working on the same type of mechanism for email...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From br@brianrosen.net Thu Aug 22 14:37:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24FA21F8E21 for ; Thu, 22 Aug 2013 14:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx3PM7EqEkcr for ; Thu, 22 Aug 2013 14:37:41 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id A92C721F8436 for ; Thu, 22 Aug 2013 14:37:40 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so2369593pbb.34 for ; Thu, 22 Aug 2013 14:37:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gtAdpFYcDuIZCTCAJx7kuxjYtJddycX0YMUCFRkhWPU=; b=Wh5gP7kO284qbjlD3m3zelmTtuoH0oRBvax8MzdLQ/orsc2p0fTtVGLHrR8jqWs7SB 7hsPi0mUWr0IQrfPVwWa1OZIeBfH/sfmXFlKqmsZe5584AyookH5Qu7wYxq5kTrnTyLe iTktSxSNo9xh0BDSP0+i+4PrFNHVNWAHtyBRp+SgKBQAf3TZU8fXY54uXJmOWAGF1D0Z OYKXITsVqmRk5FUFUBxeOjtaqxltfiqEBhRydocIK0F69MMpXy6gpWOll6EN8Z+Rls8t DLsxMGACJ5VWwXz5ylSO5MznTBjp3Tcy9H10MBCe96D1E38H/9fpShaUM5h5+iuLbXS8 csZA== X-Gm-Message-State: ALoCoQnb5DE3/oUeixcnVllS/IVD7QVI5/jBzP4csHMWHYBHNyowH62cghNFXOvq6GWFrW8ZEx0+ MIME-Version: 1.0 X-Received: by 10.66.192.132 with SMTP id hg4mr7698172pac.84.1377207449059; Thu, 22 Aug 2013 14:37:29 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Thu, 22 Aug 2013 14:37:28 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> Date: Thu, 22 Aug 2013 17:37:28 -0400 Message-ID: From: Brian Rosen To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7bdc93cac893d004e4901801 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 21:37:45 -0000 --047d7bdc93cac893d004e4901801 Content-Type: text/plain; charset=ISO-8859-1 Actually, we DO know how to solve most of the problem. We have pretty good databases that, given enough input, can give you a decent name (i.e. the real one). We further could combine a user request with such validation to allow the kinds of self representation freedom, within limits, that seems desirable. There are ways to game any such system, and I would not claim otherwise. But you can't dispute the basics that we can provide decent authentication of name. The systems we have now could tell you the difference between stamford and stanford. They probably would not let you claim Flu Ffy as your actual name. They would not let you claim HSBC Bank. I think your fundamental assumption that we will fail on human readable names is incorrect, although it will not be as reliable as the calling telephone number. Given user interfaces, I think we (at some point) must deal with human readable names, because we are not going to get people to only accept calls from people already in their address books, and we are not going to be able to get humans to recognize a phone number they have not yet seen. Brian On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennings (fluffy) wrote: > > On Aug 19, 2013, at 11:12 AM, Richard Shockey wrote: > > > Remember those databases are already in existence now. Phone companies > and > > others have the data. A binding of number to "preferred display name" > > determined by the number holder as part of the service should be doable. > > I have not checked into the regulation but as far as I can tell, in Canada > end consumers can request whatever they want to be put in this database as > long as it is not profane (and reading the white pages, there is some > pretty funny stuff ). I have not seen what happens if I request "HSBC Bank" > but "Flu Ffy" seems to be OK. > > And this does not even get in to the www.stamford.edu problem ( This > organization advertises all over Thailand - check out my photo at > http://www.flickr.com/photos/cullenfluffyjennings/9570844196/ I > particularly love their truth in advertising tag line of "The Difference is > Real" ). > > Given we don't really know how to solve this problem, and we are dealing > with the internet where in some countries "Bank of America" may not be the > same organization it is in the US and they don't care about US trademark > laws, I think we will simply fail on human readable names and instead need > to focus on the unique verifiable identifiers and allow other mechanisms to > map the unique identifiers to things that make sense to the human user in > that users context. > > > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7bdc93cac893d004e4901801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually, we DO know how to solve most of the problem. We = have pretty good databases that, given enough input, can give you a decent = name (i.e. the real one). =A0We further could combine a user request with s= uch validation to allow the kinds of self representation freedom, within li= mits, that seems desirable. =A0

There are ways to game any such system, and I would not clai= m otherwise. =A0But you can't dispute the basics that we can provide de= cent authentication of name. =A0The systems we have now could tell you the = difference between stamford and stanford. =A0They probably would not let yo= u claim Flu Ffy as your actual name. =A0They would not let you claim HSBC B= ank.

I think your fundamental assumption that we will fail o= n human readable names is incorrect, although it will not be as reliable as= the calling telephone number. =A0Given user interfaces, I think we (at som= e point) must deal with human readable names, because we are not going to g= et people to only accept calls from people already in their address books, = and we are not going to be able to get humans to recognize a phone number t= hey have not yet seen.

Brian


On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennings (= fluffy) <fluffy@cisco.com> wrote:

On Aug 19, 2013, at 11:12 AM, Richard Shockey <richard@shockey.us> wrote:

> Remember those databases are already in existence now. Phone companies= and
> others have the data. A binding of number to "preferred display n= ame"
> determined by the number holder as part of the service should be doabl= e.

I have not checked into the regulation but as far as I can tell, in C= anada end consumers can request whatever they want to be put in this databa= se as long as it is not profane (and reading the white pages, there is some= pretty funny stuff ). I have not seen what happens if I request "HSBC= Bank" but "Flu Ffy" seems to be OK.

And this does not even get in to the www.stamford.edu problem ( This organization advertises= all over Thailand - check out my photo at http://www.flic= kr.com/photos/cullenfluffyjennings/9570844196/ =A0 I particularly love = their truth in advertising tag line of "The Difference is Real" )= .

Given we don't really know how to solve this problem, and we are dealin= g with the internet where in some countries "Bank of America" may= not be the same organization it is in the US and they don't care about= US trademark laws, I think we will simply fail on human readable names and= instead need to focus on the unique verifiable identifiers and allow other= mechanisms to map the unique identifiers to things that make sense to the = human user in that users context.






_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--047d7bdc93cac893d004e4901801-- From caryfitz@employees.org Thu Aug 22 17:24:12 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD09211E8297 for ; Thu, 22 Aug 2013 17:24:12 -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=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kPYkgFBMi2B for ; Thu, 22 Aug 2013 17:24:08 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id AA89B11E812E for ; Thu, 22 Aug 2013 17:24:03 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 542785FBA; Thu, 22 Aug 2013 17:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=NV/bR4m3LFcW/nh6fefpzu5FI8Y=; b= pwQ/V6WtGiVyoDvaVkWVFJRE/STe6Fq4hasZS7hKoT7pE+dTLH+RUybKRhJ+kLzX KRWIEKEIWv4ZcQKSpvFHtKDSfx3fpMlwstnTvo23xNbvUvXwcDO55nmVnpJ4K1mj pwRn9T6mL/PG2r0wvxOeX09AhNOjbIoU/dNFEfWpD2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=dUu3oIm1UWuMBoApZjyBBM49A2 XhlEm2Ih1zJ3Nt+rxBdEzBu7bCQL5zrrf7aRT7jnlpvgh6UwGKjEaQmj+0X+r8++ 5o2tu81tc/+6IY5hyAwbNYZ7tLKjnqi+yNK7lSaO6fRkZ6Jt2C6WO6Z1L5sLg7XK WPaGIDJuvrcQdPRtg= Received: from [192.168.1.2] (c-24-7-29-157.hsd1.ca.comcast.net [24.7.29.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: caryfitz) by banjo.employees.org (Postfix) with ESMTPSA id 2099E5FAF; Thu, 22 Aug 2013 17:24:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_79BC5BEB-F6F9-468F-A22B-7CE9A851E7E5" From: Cary FitzGerald In-Reply-To: Date: Thu, 22 Aug 2013 17:23:54 -0700 Message-Id: <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> To: Brian Rosen X-Mailer: Apple Mail (2.1283) Cc: "Cullen Jennings \(fluffy\)" , "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 00:24:12 -0000 --Apple-Mail=_79BC5BEB-F6F9-468F-A22B-7CE9A851E7E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The problem of finding a database to look up a number doesn't seem like = an (IETF) standards issue, at best it's for a best practices, for both = reverse lookups and UX. In this chain: me <- my provider <- white/pink/red providers <- shady = organization with a gateway or a SIP robot money flows from right to left, and from right to left. The business = practices of the providers in the middle limit the losses they are = willing to tolerate. Given enough motivation, the forensic tools exist = to find the rightmost and the leftmost organizations to pay the bill. = Someone's paying the freight, even if it's fractions of cents per = minute. So at some level, there is a chain of trust that is as reliable = as a credit card transaction (at the least!). However, as you move across this chain (let's focus on the left to right = direction), there is no corresponding moral or legal responsibility or = practice to validate identity. Sometimes the chain of trust is = transparent, sometimes it's not. =46rom time to time, trust holds in = ways that are at odds with called partys' common sense, hence the = stamford/stanford and Flu Fly...HSBC Bank continuum. We can describe a system of identity with E.164 or the like; we can talk = about how to make those identities to access mechanisms; we can develop = ways to map the access to the databases, and we can secure parts of that = chain from various attacks, but we can't give meaning to the data that = it doesn't have. That's a social/regulatory/business practice problem. I am not arguing to do nothing, but I think that we should clearly = classify the issues and not try to force a technological solution to a = business problem. My worry for stir is that a lot of the technological = solutions feel like solutions for other related problems this community = has run up against in the past. Cary. On Aug 22, 2013, at 2:37 PM, Brian Rosen wrote: > Actually, we DO know how to solve most of the problem. We have pretty = good databases that, given enough input, can give you a decent name = (i.e. the real one). We further could combine a user request with such = validation to allow the kinds of self representation freedom, within = limits, that seems desirable. =20 >=20 > There are ways to game any such system, and I would not claim = otherwise. But you can't dispute the basics that we can provide decent = authentication of name. The systems we have now could tell you the = difference between stamford and stanford. They probably would not let = you claim Flu Ffy as your actual name. They would not let you claim = HSBC Bank. >=20 > I think your fundamental assumption that we will fail on human = readable names is incorrect, although it will not be as reliable as the = calling telephone number. Given user interfaces, I think we (at some = point) must deal with human readable names, because we are not going to = get people to only accept calls from people already in their address = books, and we are not going to be able to get humans to recognize a = phone number they have not yet seen. >=20 > Brian >=20 >=20 > On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennings (fluffy) = wrote: >=20 > On Aug 19, 2013, at 11:12 AM, Richard Shockey = wrote: >=20 > > Remember those databases are already in existence now. Phone = companies and > > others have the data. A binding of number to "preferred display = name" > > determined by the number holder as part of the service should be = doable. >=20 > I have not checked into the regulation but as far as I can tell, in = Canada end consumers can request whatever they want to be put in this = database as long as it is not profane (and reading the white pages, = there is some pretty funny stuff ). I have not seen what happens if I = request "HSBC Bank" but "Flu Ffy" seems to be OK. >=20 > And this does not even get in to the www.stamford.edu problem ( This = organization advertises all over Thailand - check out my photo at = http://www.flickr.com/photos/cullenfluffyjennings/9570844196/ I = particularly love their truth in advertising tag line of "The Difference = is Real" ). >=20 > Given we don't really know how to solve this problem, and we are = dealing with the internet where in some countries "Bank of America" may = not be the same organization it is in the US and they don't care about = US trademark laws, I think we will simply fail on human readable names = and instead need to focus on the unique verifiable identifiers and allow = other mechanisms to map the unique identifiers to things that make sense = to the human user in that users context. >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_79BC5BEB-F6F9-468F-A22B-7CE9A851E7E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 The = problem of finding a database to look up a number doesn't seem like an = (IETF) standards issue, at best it's for a best practices, for both = reverse lookups and UX.


In this = chain:

me <- my provider <- = white/pink/red providers <- shady organization with a gateway or a = SIP robot

money flows from right to left, and = from right to left.  The business practices of the providers in the = middle limit the losses they are willing to tolerate.  Given enough = motivation, the forensic tools exist to find the rightmost and the = leftmost organizations to pay the bill.  Someone's paying the = freight, even if it's fractions of cents per minute.  So at some = level, there is a chain of trust that is as reliable as a credit card = transaction (at the least!).

However, as you = move across this chain (let's focus on the left to right direction), = there is no corresponding moral or legal responsibility or practice to = validate identity.  Sometimes the chain of trust is transparent, = sometimes it's not.  =46rom time to time, trust holds in ways that = are at odds with called partys' common sense, hence the = stamford/stanford and Flu Fly...HSBC Bank = continuum.

We can describe a system of identity = with E.164 or the like; we can talk about how to make those identities = to access mechanisms; we can develop ways to map the access to the = databases, and we can secure parts of that chain from various attacks, = but we can't give meaning to the data that it doesn't have.  That's = a social/regulatory/business practice = problem.

I am not arguing to do nothing, but I = think that we should clearly classify the issues and not try to force a = technological solution to a business problem.  My worry for stir is = that a lot of the technological solutions feel like solutions for other = related problems this community has run up against in the = past.

Cary.

On Aug 22, 2013, at 2:37 PM, Brian Rosen wrote:

Actually, we DO know how to solve most of the problem. We = have pretty good databases that, given enough input, can give you a = decent name (i.e. the real one).  We further could combine a user = request with such validation to allow the kinds of self representation = freedom, within limits, that seems desirable.  

There are ways to game any such system, and I would not = claim otherwise.  But you can't dispute the basics that we can = provide decent authentication of name.  The systems we have now = could tell you the difference between stamford and stanford.  They = probably would not let you claim Flu Ffy as your actual name.  They = would not let you claim HSBC Bank.

I think your fundamental assumption that we will = fail on human readable names is incorrect, although it will not be as = reliable as the calling telephone number.  Given user interfaces, I = think we (at some point) must deal with human readable names, because we = are not going to get people to only accept calls from people already in = their address books, and we are not going to be able to get humans to = recognize a phone number they have not yet seen.

Brian


On Thu, Aug 22, = 2013 at 10:53 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

On Aug 19, 2013, at 11:12 AM, Richard Shockey <richard@shockey.us> wrote:

> Remember those databases are already in existence now. Phone = companies and
> others have the data. A binding of number to "preferred display = name"
> determined by the number holder as part of the service should be = doable.

I have not checked into the regulation but as far as I can tell, = in Canada end consumers can request whatever they want to be put in this = database as long as it is not profane (and reading the white pages, = there is some pretty funny stuff ). I have not seen what happens if I = request "HSBC Bank" but "Flu Ffy" seems to be OK.

And this does not even get in to the www.stamford.edu problem ( This organization = advertises all over Thailand - check out my photo at http://www.flickr.com/photos/cullenfluffyjennings/957084= 4196/   I particularly love their truth in advertising tag line = of "The Difference is Real" ).

Given we don't really know how to solve this problem, and we are dealing = with the internet where in some countries "Bank of America" may not be = the same organization it is in the US and they don't care about US = trademark laws, I think we will simply fail on human readable names and = instead need to focus on the unique verifiable identifiers and allow = other mechanisms to map the unique identifiers to things that make sense = to the human user in that users context.






_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_79BC5BEB-F6F9-468F-A22B-7CE9A851E7E5-- From br@brianrosen.net Fri Aug 23 07:00:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CB911E817A for ; Fri, 23 Aug 2013 07:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.862 X-Spam-Level: X-Spam-Status: No, score=-101.862 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWse-8mPBVVP for ; Fri, 23 Aug 2013 07:00:43 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id E6D3611E82F5 for ; Fri, 23 Aug 2013 07:00:41 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so709475pdi.5 for ; Fri, 23 Aug 2013 07:00:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MCSWFCOtQIgaRmH1YvtGB4mFwSqwe5TT1SLL4vg7E2w=; b=nlqlBXILAPoCrRKWq/uTmQzrHplsWumW6mUDR8uR797NFlvJwvHHbuyHlwagmhAkfU I9nzEgTCv2JGkuxJSEvmtRSVL+yOLgW6kNyVcJy6N+mYd8CJ42AtaoATAk9k0bJnqZeS WuaddYe28yvq9gWWgRNExd5yiFeK7ckKFASczJVIRe55FKeDyXpluDGcqL3d7jYgwgvj x+ulqUzyMknZc7X9OLIGbVTTbdvk9yoxMl1dztExD95x9FKGSxGfGOItV9Eg8MqCVLuq WATxFaH8uvlEbd2IaSIRUbo+d1cRqJM3+qeevaANu8OVrU/EJXHbRdMcP7B7wYSEnasE OfyQ== X-Gm-Message-State: ALoCoQnRVO+EfqTah0ni8oArUumV6MIEwizITvxdGeTv2RFiFInfWaUTwXoGRvSY5Ity6WD4SUrh MIME-Version: 1.0 X-Received: by 10.68.12.97 with SMTP id x1mr11061627pbb.150.1377266440475; Fri, 23 Aug 2013 07:00:40 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Fri, 23 Aug 2013 07:00:40 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> Date: Fri, 23 Aug 2013 10:00:40 -0400 Message-ID: From: Brian Rosen To: Cary FitzGerald Content-Type: multipart/alternative; boundary=bcaec5215f91f22c9204e49dd4a6 Cc: "Cullen Jennings \(fluffy\)" , "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 14:00:47 -0000 --bcaec5215f91f22c9204e49dd4a6 Content-Type: text/plain; charset=ISO-8859-1 Look at the thread again. Tim proposed that the paradigm for caller name be changed so that the origination side used existing display name, and P-A-ID to send caller name through signaling. If that was the paradigm, then the recipient wants some sort of assurance the name is genuine, assurance obtained on the origination side and sent through the signaling to the termination side. That is the standardization required. This changes the flow of money. Today, the termination side pays for a data dip, either to an originating SP database or some independent database. The proposal to to change that so that there is no specific charge, it just comes on the wire. TNSTAFL, it's in the general peering relationship costs. On Thu, Aug 22, 2013 at 8:23 PM, Cary FitzGerald wrote: > The problem of finding a database to look up a number doesn't seem like an > (IETF) standards issue, at best it's for a best practices, for both reverse > lookups and UX. > > > In this chain: > > me <- my provider <- white/pink/red providers <- shady organization with a > gateway or a SIP robot > > money flows from right to left, and from right to left. The business > practices of the providers in the middle limit the losses they are willing > to tolerate. Given enough motivation, the forensic tools exist to find the > rightmost and the leftmost organizations to pay the bill. Someone's paying > the freight, even if it's fractions of cents per minute. So at some level, > there is a chain of trust that is as reliable as a credit card transaction > (at the least!). > > However, as you move across this chain (let's focus on the left to right > direction), there is no corresponding moral or legal responsibility or > practice to validate identity. Sometimes the chain of trust is > transparent, sometimes it's not. From time to time, trust holds in ways > that are at odds with called partys' common sense, hence the > stamford/stanford and Flu Fly...HSBC Bank continuum. > > We can describe a system of identity with E.164 or the like; we can talk > about how to make those identities to access mechanisms; we can develop > ways to map the access to the databases, and we can secure parts of that > chain from various attacks, but we can't give meaning to the data that it > doesn't have. That's a social/regulatory/business practice problem. > > I am not arguing to do nothing, but I think that we should clearly > classify the issues and not try to force a technological solution to a > business problem. My worry for stir is that a lot of the technological > solutions feel like solutions for other related problems this community has > run up against in the past. > > Cary. > > On Aug 22, 2013, at 2:37 PM, Brian Rosen wrote: > > Actually, we DO know how to solve most of the problem. We have pretty good > databases that, given enough input, can give you a decent name (i.e. the > real one). We further could combine a user request with such validation to > allow the kinds of self representation freedom, within limits, that seems > desirable. > > There are ways to game any such system, and I would not claim otherwise. > But you can't dispute the basics that we can provide decent authentication > of name. The systems we have now could tell you the difference between > stamford and stanford. They probably would not let you claim Flu Ffy as > your actual name. They would not let you claim HSBC Bank. > > I think your fundamental assumption that we will fail on human readable > names is incorrect, although it will not be as reliable as the calling > telephone number. Given user interfaces, I think we (at some point) must > deal with human readable names, because we are not going to get people to > only accept calls from people already in their address books, and we are > not going to be able to get humans to recognize a phone number they have > not yet seen. > > Brian > > > On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > >> >> On Aug 19, 2013, at 11:12 AM, Richard Shockey wrote: >> >> > Remember those databases are already in existence now. Phone companies >> and >> > others have the data. A binding of number to "preferred display name" >> > determined by the number holder as part of the service should be doable. >> >> I have not checked into the regulation but as far as I can tell, in >> Canada end consumers can request whatever they want to be put in this >> database as long as it is not profane (and reading the white pages, there >> is some pretty funny stuff ). I have not seen what happens if I request >> "HSBC Bank" but "Flu Ffy" seems to be OK. >> >> And this does not even get in to the www.stamford.edu problem ( This >> organization advertises all over Thailand - check out my photo at >> http://www.flickr.com/photos/cullenfluffyjennings/9570844196/ I >> particularly love their truth in advertising tag line of "The Difference is >> Real" ). >> >> Given we don't really know how to solve this problem, and we are dealing >> with the internet where in some countries "Bank of America" may not be the >> same organization it is in the US and they don't care about US trademark >> laws, I think we will simply fail on human readable names and instead need >> to focus on the unique verifiable identifiers and allow other mechanisms to >> map the unique identifiers to things that make sense to the human user in >> that users context. >> >> >> >> >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > > --bcaec5215f91f22c9204e49dd4a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Look at the thread again. =A0Tim proposed that the paradig= m for caller name be changed so that the origination side used existing dis= play name, and P-A-ID to send caller name through signaling. =A0If that was= the paradigm, then the recipient wants some sort of assurance the name is = genuine, assurance obtained on the origination side and sent through the si= gnaling to the termination side. =A0That is the standardization required.
This changes the flow of money. =A0Today, the termination si= de pays for a data dip, either to an originating SP database or some indepe= ndent database. =A0The proposal to to change that so that there is no speci= fic charge, it just comes on the wire. =A0 TNSTAFL, it's in the general= peering relationship costs.




On Thu, Aug 22, 2013 at 8:23 PM, Cary FitzGerald <caryfitz@employees.org> wrote:
The prob= lem of finding a database to look up a number doesn't seem like an (IET= F) standards issue, at best it's for a best practices, for both reverse= lookups and UX.


In this chain:

me <- my provider <- white/pi= nk/red providers <- shady organization with a gateway or a SIP robot

money flows from right to left, and from right to left.= =A0The business practices of the providers in the middle limit the losses = they are willing to tolerate. =A0Given enough motivation, the forensic tool= s exist to find the rightmost and the leftmost organizations to pay the bil= l. =A0Someone's paying the freight, even if it's fractions of cents= per minute. =A0So at some level, there is a chain of trust that is as reli= able as a credit card transaction (at the least!).

However, as you move across this chain (let's focus= on the left to right direction), there is no corresponding moral or legal = responsibility or practice to validate identity. =A0Sometimes the chain of = trust is transparent, sometimes it's not. =A0From time to time, trust h= olds in ways that are at odds with called partys' common sense, hence t= he stamford/stanford and Flu Fly...HSBC Bank continuum.

We can describe a system of identity with E.164 or the = like; we can talk about how to make those identities to access mechanisms; = we can develop ways to map the access to the databases, and we can secure p= arts of that chain from various attacks, but we can't give meaning to t= he data that it doesn't have. =A0That's a social/regulatory/busines= s practice problem.

I am not arguing to do nothing, but I think that we sho= uld clearly classify the issues and not try to force a technological soluti= on to a business problem. =A0My worry for stir is that a lot of the technol= ogical solutions feel like solutions for other related problems this commun= ity has run up against in the past.

Cary.

= On Aug 22, 2013, at 2:37 PM, Brian Rosen wrote:

Actually, we DO know how to solve most of the problem. We = have pretty good databases that, given enough input, can give you a decent = name (i.e. the real one). =A0We further could combine a user request with s= uch validation to allow the kinds of self representation freedom, within li= mits, that seems desirable. =A0

There are ways to game any such system, and I would not clai= m otherwise. =A0But you can't dispute the basics that we can provide de= cent authentication of name. =A0The systems we have now could tell you the = difference between stamford and stanford. =A0They probably would not let yo= u claim Flu Ffy as your actual name. =A0They would not let you claim HSBC B= ank.

I think your fundamental assumption that we will fail o= n human readable names is incorrect, although it will not be as reliable as= the calling telephone number. =A0Given user interfaces, I think we (at som= e point) must deal with human readable names, because we are not going to g= et people to only accept calls from people already in their address books, = and we are not going to be able to get humans to recognize a phone number t= hey have not yet seen.

Brian


On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennings (= fluffy) <fluffy@cisco.com> wrote:

On Aug 19, 2013, at 11:12 AM, Richard Shockey <richard@shockey.us> wrote:

> Remember those databases are already in existence now. Phone companies= and
> others have the data. A binding of number to "preferred display n= ame"
> determined by the number holder as part of the service should be doabl= e.

I have not checked into the regulation but as far as I can tell, in C= anada end consumers can request whatever they want to be put in this databa= se as long as it is not profane (and reading the white pages, there is some= pretty funny stuff ). I have not seen what happens if I request "HSBC= Bank" but "Flu Ffy" seems to be OK.

And this does not even get in to the www.stamford.edu problem ( This organization advertise= s all over Thailand - check out my photo at http://www.fli= ckr.com/photos/cullenfluffyjennings/9570844196/ =A0 I particularly love= their truth in advertising tag line of "The Difference is Real" = ).

Given we don't really know how to solve this problem, and we are dealin= g with the internet where in some countries "Bank of America" may= not be the same organization it is in the US and they don't care about= US trademark laws, I think we will simply fail on human readable names and= instead need to focus on the unique verifiable identifiers and allow other= mechanisms to map the unique identifiers to things that make sense to the = human user in that users context.






_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://= www.ietf.org/mailman/listinfo/stir

--bcaec5215f91f22c9204e49dd4a6-- From hadriel.kaplan@oracle.com Fri Aug 23 08:16:34 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C8311E8170 for ; Fri, 23 Aug 2013 08:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ogYIZ0ltuVE for ; Fri, 23 Aug 2013 08:16:28 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 394B611E8115 for ; Fri, 23 Aug 2013 08:16:28 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7NFGMsZ004616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Aug 2013 15:16:23 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7NFGLja016724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 15:16:22 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7NFGLgu006586; Fri, 23 Aug 2013 15:16:21 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Aug 2013 08:16:21 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 23 Aug 2013 11:16:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 15:16:34 -0000 On Aug 23, 2013, at 10:00 AM, Brian Rosen wrote: > Look at the thread again. Tim proposed that the paradigm for caller = name be changed so that the origination side used existing display name, = and P-A-ID to send caller name through signaling. If that was the = paradigm, then the recipient wants some sort of assurance the name is = genuine, assurance obtained on the origination side and sent through the = signaling to the termination side. That is the standardization = required. Someday maybe - but it's not in the charter for STIR, and not in scope = for now. Nothing prevents folks from working on how to accomplish it = somehow, and re-charter or create another WG for that someday. But = right now it's not our focus in this STIR WG-to-be, afaik. > This changes the flow of money. Today, the termination side pays for = a data dip, either to an originating SP database or some independent = database. The proposal to to change that so that there is no specific = charge, it just comes on the wire. TNSTAFL, it's in the general = peering relationship costs. The problem though, as has been pointed out by many folks over the past = decade we've been talking about this stuff, is that the money flow pays = for delivery of calls. The 'pink' originator and transit carriers are = paid by the sender to deliver phone calls, so the monetary incentive = model works against us. We can't blindly trust them to put in = legitimate names. Even if we used a 'secured' form of PAI header (something like = http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01), it = would ultimately require a reputation system; and deciding another = carrier is not trustworthy and thus stripping their calling names is = very problematic. It would undoubtedly result in lawsuits and = anti-competitive FTC complaints, for example. With calling numbers we think we have a way to fix it, both = technologically and pragmatically, and in such a way that it doesn't = disrupt the flow of money+incentive nor open up anti-trade issues. For = calling names the problem is much harder, and we haven't figured out a = technological and pragmatic way to fix it. -hadriel From br@brianrosen.net Fri Aug 23 10:22:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F31821F9D87 for ; Fri, 23 Aug 2013 10:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM3HR2ax5nyM for ; Fri, 23 Aug 2013 10:22:39 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3198421F9D53 for ; Fri, 23 Aug 2013 10:22:39 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so921565pbc.15 for ; Fri, 23 Aug 2013 10:22:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J4P7gCP4JIsyvbW9m0Ru+wSXbKSm9hQbPINo+9Cl/tk=; b=VTc5r9y1/m4IXqaH+iJnJmZfg4c67RkWY7SvIA7ZBIHv/wZTH6IVmwNgU7iJfaL1xz xT8IP2UQ62NrjKBij/7+i4pQubyuvFyeeM2QCTs+86KbRrQIy2mT1VSD3pYcar28Wvup XGEjZrcCFk4/Zq1c7HO66+qy/kRD/aY6Vj3mEB18AOkUee7bHLXqhlqu6bxwCfk54Sxt QM2256RHN4AaIg4mqpN30o1MzZLw3IXEaTDQMom36DAJpyq4/V1pV47HhW5q/ucPrQ1M ZGxsNR9VdzdkuVkeLwwFhReXs/dZKKtXzl2ygmBdSjXE+SxTiFEdyp6rlHnynqEqTo9z /tsA== X-Gm-Message-State: ALoCoQlmyweeprWN8CxnzIGSJ5nR96NfMUSAdTfWP8JLmboNJuSnv40GhLcdhR4NK/g3oCHWblzU MIME-Version: 1.0 X-Received: by 10.66.118.129 with SMTP id km1mr18008pab.127.1377278558902; Fri, 23 Aug 2013 10:22:38 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Fri, 23 Aug 2013 10:22:38 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> Date: Fri, 23 Aug 2013 13:22:38 -0400 Message-ID: From: Brian Rosen To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=e89a8ffbab6b42b1a104e4a0a765 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 17:22:48 -0000 --e89a8ffbab6b42b1a104e4a0a765 Content-Type: text/plain; charset=ISO-8859-1 The idea is that you get a 3rd party to provide the level of assurance, hoping that the number of such services would be small and thus the trustworhlyness of them being understood widely. The termination end can decide if it trusts that third party, and, if necessary, use an alternative service if it doesn't. The reason to keep discussing this in stir is to emphasize that the mechanism may need to carry some other data, like the assurance on the name, in addition to what we're already discussing. On Fri, Aug 23, 2013 at 11:16 AM, Hadriel Kaplan wrote: > > On Aug 23, 2013, at 10:00 AM, Brian Rosen wrote: > > > Look at the thread again. Tim proposed that the paradigm for caller > name be changed so that the origination side used existing display name, > and P-A-ID to send caller name through signaling. If that was the > paradigm, then the recipient wants some sort of assurance the name is > genuine, assurance obtained on the origination side and sent through the > signaling to the termination side. That is the standardization required. > > Someday maybe - but it's not in the charter for STIR, and not in scope for > now. Nothing prevents folks from working on how to accomplish it somehow, > and re-charter or create another WG for that someday. But right now it's > not our focus in this STIR WG-to-be, afaik. > > > > This changes the flow of money. Today, the termination side pays for a > data dip, either to an originating SP database or some independent > database. The proposal to to change that so that there is no specific > charge, it just comes on the wire. TNSTAFL, it's in the general peering > relationship costs. > > The problem though, as has been pointed out by many folks over the past > decade we've been talking about this stuff, is that the money flow pays for > delivery of calls. The 'pink' originator and transit carriers are paid by > the sender to deliver phone calls, so the monetary incentive model works > against us. We can't blindly trust them to put in legitimate names. > > Even if we used a 'secured' form of PAI header (something like > http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01), it > would ultimately require a reputation system; and deciding another carrier > is not trustworthy and thus stripping their calling names is very > problematic. It would undoubtedly result in lawsuits and anti-competitive > FTC complaints, for example. > > With calling numbers we think we have a way to fix it, both > technologically and pragmatically, and in such a way that it doesn't > disrupt the flow of money+incentive nor open up anti-trade issues. For > calling names the problem is much harder, and we haven't figured out a > technological and pragmatic way to fix it. > > -hadriel > > --e89a8ffbab6b42b1a104e4a0a765 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The idea is that you get a 3rd party to provide the level = of assurance, hoping that the number of such services would be small and th= us the trustworhlyness of them being understood widely. =A0The termination = end can decide if it trusts that third party, and, if necessary, use an alt= ernative service if it doesn't. =A0The reason to keep discussing this i= n stir is to emphasize that the mechanism may need to carry some other data= , like the assurance on the name, in addition to what we're already dis= cussing.=A0


On Fri, Aug 2= 3, 2013 at 11:16 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com= > wrote:

On Aug 23, 2013, at 10:00 AM, Brian Rosen <br@brianrosen.net> wrote:

> Look at the thread again. =A0Tim proposed that the paradigm for caller= name be changed so that the origination side used existing display name, a= nd P-A-ID to send caller name through signaling. =A0If that was the paradig= m, then the recipient wants some sort of assurance the name is genuine, ass= urance obtained on the origination side and sent through the signaling to t= he termination side. =A0That is the standardization required.

Someday maybe - but it's not in the charter for STIR, and not in = scope for now. =A0Nothing prevents folks from working on how to accomplish = it somehow, and re-charter or create another WG for that someday. =A0But ri= ght now it's not our focus in this STIR WG-to-be, afaik.


> This changes the flow of money. =A0Today, the termination side pays fo= r a data dip, either to an originating SP database or some independent data= base. =A0The proposal to to change that so that there is no specific charge= , it just comes on the wire. =A0 TNSTAFL, it's in the general peering r= elationship costs.

The problem though, as has been pointed out by many folks over the pa= st decade we've been talking about this stuff, is that the money flow p= ays for delivery of calls. =A0The 'pink' originator and transit car= riers are paid by the sender to deliver phone calls, so the monetary incent= ive model works against us. =A0We can't blindly trust them to put in le= gitimate names.

Even if we used a 'secured' form of PAI header (something like http://tools.ietf.org/html/draft-kaplan-sip-asserter-identi= ty-01), it would ultimately require a reputation system; and deciding a= nother carrier is not trustworthy and thus stripping their calling names is= very problematic. =A0It would undoubtedly result in lawsuits and anti-comp= etitive FTC complaints, for example.

With calling numbers we think we have a way to fix it, both technologically= and pragmatically, and in such a way that it doesn't disrupt the flow = of money+incentive nor open up anti-trade issues. =A0For calling names the = problem is much harder, and we haven't figured out a technological and = pragmatic way to fix it.

-hadriel


--e89a8ffbab6b42b1a104e4a0a765-- From hadriel.kaplan@oracle.com Fri Aug 23 11:44:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A3511E80C5 for ; Fri, 23 Aug 2013 11:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJmq2Yiq8BsV for ; Fri, 23 Aug 2013 11:44:34 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 737E411E80EC for ; Fri, 23 Aug 2013 11:44:34 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7NIiVXW015125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Aug 2013 18:44:33 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7NIiUB3017008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 18:44:30 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7NIiUhW017004; Fri, 23 Aug 2013 18:44:30 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Aug 2013 11:44:30 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 23 Aug 2013 14:44:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 18:44:41 -0000 On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote: > The idea is that you get a 3rd party to provide the level of = assurance, hoping that the number of such services would be small and = thus the trustworhlyness of them being understood widely. The = termination end can decide if it trusts that third party, and, if = necessary, use an alternative service if it doesn't. =20 We have that already today: just in the USA there are over a dozen LIDB = providers, and even more CNAM DB providers. The validity of the data in = them varies, but they're essentially the "3rd party" model. > The reason to keep discussing this in stir is to emphasize that the = mechanism may need to carry some other data, like the assurance on the = name, in addition to what we're already discussing.=20 That's a good point. One of the things we talked about originally was that a valid calling = number was a precursor to calling name, because the name lookup is based = on the calling number for the key. So I think for the current LIDB/CNAM = models the currently-proposed STIR in-band data is sufficient (or at = least I was thinking that way when I wrote the draft-IKES mechanism). Regardless, my concern is I can easily foresee a calling name discussion = knocking us off-the-tracks very quickly. For example I expect the = feature-creep to begin with including various other forms of name = identifiers, such as email or social-site-based names, and then getting = into the need for an IdP model, SSO/SAML/OpenID, OAuth, etc. Or we = start debating how to distinguish legitimate financial banks from blood = banks and sperm banks; or how users receiving just the string "Fidelity" = disambiguate when they get calls from: Fidelity Investments, Fidelity = National Financial, Fidelity National Information Services, USS = Fidelity, Fidelity Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, = Fidelity Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all legal, = separate entities in the US) I don't really know how to prevent such ratholes, but maybe we need a = separate mailing list for the name discussions (i.e. for a = research/design-team) to separate that stuff out and keep this one = focused on the charter's scope? -hadriel From br@brianrosen.net Fri Aug 23 12:24:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E3111E8137 for ; Fri, 23 Aug 2013 12:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJAfV2ICt0Yk for ; Fri, 23 Aug 2013 12:24:51 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7946211E8106 for ; Fri, 23 Aug 2013 12:24:51 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so1037856pad.16 for ; Fri, 23 Aug 2013 12:24:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ssxAjR8AnFGirfLqwXi9Okyr6JCo4V2DWCU68D6BYmc=; b=gwUHic8zb7FA2bEiuhgAQTbu9jQd3aGjSgBWp69maqtAWikclHGQPa0BL1+nCs3DHH Fq1wDxppCx0CJ5gNvL7XLgcEnY5skpA6zklTEtqpKWosabHwAsagL0mLujWVQZl4YQbP ddZfo3lpExsBz39a7Cng/g24QvRgY/jK79s03o3JtWK2fNfzZu2Pcq/cMV4alC/amFhA cdbq7CA/jK8wkGYVlsSlVGD9ozi6StRqbkWFUe5eTUe9oWbV9la4BwcdGF3chgTWvSzR HvDmMsXP1KQLQhPBWRCfUWKOAvjYanO74o8lLHpy6mqEJo4lI5bcF8H43E2b3yTGxsDF e7GA== X-Gm-Message-State: ALoCoQnjnGAUTvRI3TzsMsXq1HnSwVOlxthL6sr6iLudM9mDQMmtXGUyijTeCMMdUYswKiuA4buW MIME-Version: 1.0 X-Received: by 10.68.143.38 with SMTP id sb6mr1412485pbb.44.1377285891094; Fri, 23 Aug 2013 12:24:51 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Fri, 23 Aug 2013 12:24:51 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> Date: Fri, 23 Aug 2013 15:24:51 -0400 Message-ID: From: Brian Rosen To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7b2e3fbe4b0f4304e4a25c78 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 19:24:58 -0000 --047d7b2e3fbe4b0f4304e4a25c78 Content-Type: text/plain; charset=ISO-8859-1 The only think we have now is a way for the termination end to use an alternate source of names. In the scheme we're discussing, the primary mechanism DOES NOT use a database queried by TN at the termination, except when it doesn't like the trustworthlyness of the originator's validation service, or when there is no name, or no validation - i.e. fall back. The primary mechanism would be to use the display name in SIP, with a new validation thingie in the stir signature, from a trusted 3rd party (hopefully one of only a few of them). We don't do that today. Let me emphasize: All I want out of stir is a way to extend the signature to cover whatever we come up with. That "whatever" can be done in a recharter of stir, later, or it could be done in a separate WG, as long as we can extend the signature to cover other stuff. I think another mail list is a good idea, but that means we have to come up with another acronym! Brian On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan wrote: > > On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote: > > > The idea is that you get a 3rd party to provide the level of assurance, > hoping that the number of such services would be small and thus the > trustworhlyness of them being understood widely. The termination end can > decide if it trusts that third party, and, if necessary, use an alternative > service if it doesn't. > > We have that already today: just in the USA there are over a dozen LIDB > providers, and even more CNAM DB providers. The validity of the data in > them varies, but they're essentially the "3rd party" model. > > > > The reason to keep discussing this in stir is to emphasize that the > mechanism may need to carry some other data, like the assurance on the > name, in addition to what we're already discussing. > > That's a good point. > > One of the things we talked about originally was that a valid calling > number was a precursor to calling name, because the name lookup is based on > the calling number for the key. So I think for the current LIDB/CNAM > models the currently-proposed STIR in-band data is sufficient (or at least > I was thinking that way when I wrote the draft-IKES mechanism). > > Regardless, my concern is I can easily foresee a calling name discussion > knocking us off-the-tracks very quickly. For example I expect the > feature-creep to begin with including various other forms of name > identifiers, such as email or social-site-based names, and then getting > into the need for an IdP model, SSO/SAML/OpenID, OAuth, etc. Or we start > debating how to distinguish legitimate financial banks from blood banks and > sperm banks; or how users receiving just the string "Fidelity" disambiguate > when they get calls from: Fidelity Investments, Fidelity National > Financial, Fidelity National Information Services, USS Fidelity, Fidelity > Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, > Fidelity WFID, or Fidelity Township NJ. (all legal, separate entities in > the US) > > I don't really know how to prevent such ratholes, but maybe we need a > separate mailing list for the name discussions (i.e. for a > research/design-team) to separate that stuff out and keep this one focused > on the charter's scope? > > -hadriel > > --047d7b2e3fbe4b0f4304e4a25c78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The only think we have now is a way for the termination en= d to use an alternate source of names. =A0In the scheme we're discussin= g, the primary mechanism DOES NOT use a database queried by TN at the termi= nation, except when it doesn't like the trustworthlyness of the origina= tor's validation service, or when there is no name, or no validation - = i.e. fall back.

The primary mechanism would be to use the display name in SI= P, with a new validation thingie in the stir signature, from a trusted 3rd = party (hopefully one of only a few of them). =A0We don't do that today.= =A0

Let me emphasize:

All I want out of = stir is a way to extend the signature to cover whatever we come up with. = =A0That "whatever" can be done in a recharter of stir, later, or = it could be done in a separate WG, as long as we can extend the signature t= o cover other stuff.

I think another mail list is a good idea, but that mean= s we have to come up with another acronym!

Brian



On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan <hadriel.kaplan@or= acle.com> wrote:

On Aug 23, 2013, at 1:22 PM, Brian Rosen <br@brianrosen.net> wrote:

> The idea is that you get a 3rd party to provide the level of assurance= , hoping that the number of such services would be small and thus the trust= worhlyness of them being understood widely. =A0The termination end can deci= de if it trusts that third party, and, if necessary, use an alternative ser= vice if it doesn't.

We have that already today: just in the USA there are over a dozen LI= DB providers, and even more CNAM DB providers. =A0The validity of the data = in them varies, but they're essentially the "3rd party" model= .


> The reason to keep discussing this in stir is to emphasize that the me= chanism may need to carry some other data, like the assurance on the name, = in addition to what we're already discussing.

That's a good point.

One of the things we talked about originally was that a valid calling numbe= r was a precursor to calling name, because the name lookup is based on the = calling number for the key. =A0So I think for the current LIDB/CNAM models = the currently-proposed STIR in-band data is sufficient (or at least I was t= hinking that way when I wrote the draft-IKES mechanism).

Regardless, my concern is I can easily foresee a calling name discussion kn= ocking us off-the-tracks very quickly. =A0For example I expect the feature-= creep to begin with including various other forms of name identifiers, such= as email or social-site-based names, and then getting into the need for an= IdP model, SSO/SAML/OpenID, OAuth, etc. =A0Or we start debating how to dis= tinguish legitimate financial banks from blood banks and sperm banks; or ho= w users receiving just the string "Fidelity" disambiguate when th= ey get calls from: Fidelity Investments, Fidelity National Financial, Fidel= ity National Information Services, USS Fidelity, Fidelity Records, Fidelity= IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fid= elity Township NJ. (all legal, separate entities in the US)

I don't really know how to prevent such ratholes, but maybe we need a s= eparate mailing list for the name discussions (i.e. for a research/design-t= eam) to separate that stuff out and keep this one focused on the charter= 9;s scope?

-hadriel


--047d7b2e3fbe4b0f4304e4a25c78-- From timothy.dwight@verizon.com Fri Aug 23 12:38:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7792011E8106 for ; Fri, 23 Aug 2013 12:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdkVtoJv5Mhm for ; Fri, 23 Aug 2013 12:38:18 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id CA02011E80E4 for ; Fri, 23 Aug 2013 12:38:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 23 Aug 2013 19:38:16 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,943,1367971200"; d="scan'208";a="533478359" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 23 Aug 2013 19:38:12 +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, 23 Aug 2013 15:38:11 -0400 To: Hadriel Kaplan , Brian Rosen Date: Fri, 23 Aug 2013 15:38:11 -0400 Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: Ac6gMNc5ilOvoJMpTWCo0+JigGA5hwAAuXYA Message-ID: <2B0F677F0B95454297753F58D4A07FA3012AF557CB@FHDP1LUMXC7V31.us.one.verizon.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.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 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 19:38:23 -0000 Henning previously suggested what I understood to be a "database of names" = into which entities concerned that their name might be spoofed, could regis= ter themselves. Banks for example. The idea was that to validate a "calli= ng name" you could look up that name in this database, and get in return a = list of phone numbers they've registered as numbers they use to call people= . You could then check to see if the [validated] calling number was on tha= t list. That seems to me to have at least one hole, though. Duplicate names. You = can't disallow them because in the real world it happens. But maybe in the= process of registering your name, you get a unique identifier. And that i= dentifier gets signaled in some new parameter, in addition to the textual n= ame. The validation function could then look up this identifier to determi= ne (a) what name should be displayed, and (b) whether the [validated] calli= ng number is registered as associated with that name. =20 Brian is correct that I suggested the validation function might be on the o= riginating side of the call; which would require some way to carry the resu= lt and the entity claiming to have produced that result, in the signaling m= essage. That doesn't of course prevent the terminating network validating it again,= if the entity claiming to have performed that validation, isn't deemed tru= stworthy.=20 I'm happy to take the topic of how best to authenticate calling name, to an= other list. But if the initial STIR work specifies signaling enhancements,= I would like to see them include a way to convey the result of a calling n= ame validation performed somewhere upstream. Nothing about how to do the v= alidation [yet]. Let the folks who elect to post to this other list, work = on that. Just a container for the result. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Friday, August 23, 2013 1:44 PM To: Brian Rosen Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework) On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote: > The idea is that you get a 3rd party to provide the level of assurance, h= oping that the number of such services would be small and thus the trustwor= hlyness of them being understood widely. The termination end can decide if= it trusts that third party, and, if necessary, use an alternative service = if it doesn't. =20 We have that already today: just in the USA there are over a dozen LIDB pro= viders, and even more CNAM DB providers. The validity of the data in them = varies, but they're essentially the "3rd party" model. > The reason to keep discussing this in stir is to emphasize that the mecha= nism may need to carry some other data, like the assurance on the name, in = addition to what we're already discussing.=20 That's a good point. One of the things we talked about originally was that a valid calling numbe= r was a precursor to calling name, because the name lookup is based on the = calling number for the key. So I think for the current LIDB/CNAM models th= e currently-proposed STIR in-band data is sufficient (or at least I was thi= nking that way when I wrote the draft-IKES mechanism). Regardless, my concern is I can easily foresee a calling name discussion kn= ocking us off-the-tracks very quickly. For example I expect the feature-cr= eep to begin with including various other forms of name identifiers, such a= s email or social-site-based names, and then getting into the need for an I= dP model, SSO/SAML/OpenID, OAuth, etc. Or we start debating how to disting= uish legitimate financial banks from blood banks and sperm banks; or how us= ers receiving just the string "Fidelity" disambiguate when they get calls f= rom: Fidelity Investments, Fidelity National Financial, Fidelity National I= nformation Services, USS Fidelity, Fidelity Records, Fidelity IL, Fidelity = MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fidelity Township= NJ. (all legal, separate entities in the US) I don't really know how to prevent such ratholes, but maybe we need a separ= ate mailing list for the name discussions (i.e. for a research/design-team)= to separate that stuff out and keep this one focused on the charter's scop= e? -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Fri Aug 23 12:40:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CF611E810E for ; Fri, 23 Aug 2013 12:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce-guZZRLcDn for ; Fri, 23 Aug 2013 12:40:12 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7713711E80E4 for ; Fri, 23 Aug 2013 12:40:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 23 Aug 2013 19:40:12 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,943,1367971200"; d="scan'208,217";a="532620629" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 23 Aug 2013 19:40:11 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Fri, 23 Aug 2013 15:40:11 -0400 To: Brian Rosen , Hadriel Kaplan Date: Fri, 23 Aug 2013 15:40:10 -0400 Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: Ac6gNncRqONE8PxaRgWKI618wvzonwAAhp5w Message-ID: <2B0F677F0B95454297753F58D4A07FA3012AF557CE@FHDP1LUMXC7V31.us.one.verizon.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.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: multipart/alternative; boundary="_000_2B0F677F0B95454297753F58D4A07FA3012AF557CEFHDP1LUMXC7V3_" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 19:40:19 -0000 --_000_2B0F677F0B95454297753F58D4A07FA3012AF557CEFHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Friday, August 23, 2013 2:25 PM To: Hadriel Kaplan Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework) The only think we have now is a way for the termination end to use an alter= nate source of names. In the scheme we're discussing, the primary mechanis= m DOES NOT use a database queried by TN at the termination, except when it = doesn't like the trustworthlyness of the originator's validation service, o= r when there is no name, or no validation - i.e. fall back. The primary mechanism would be to use the display name in SIP, with a new v= alidation thingie in the stir signature, from a trusted 3rd party (hopefull= y one of only a few of them). We don't do that today. Let me emphasize: All I want out of stir is a way to extend the signature to cover whatever w= e come up with. That "whatever" can be done in a recharter of stir, later,= or it could be done in a separate WG, as long as we can extend the signatu= re to cover other stuff. I think another mail list is a good idea, but that means we have to come up= with another acronym! Brian On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan > wrote: On Aug 23, 2013, at 1:22 PM, Brian Rosen > wrote: > The idea is that you get a 3rd party to provide the level of assurance, h= oping that the number of such services would be small and thus the trustwor= hlyness of them being understood widely. The termination end can decide if= it trusts that third party, and, if necessary, use an alternative service = if it doesn't. We have that already today: just in the USA there are over a dozen LIDB pro= viders, and even more CNAM DB providers. The validity of the data in them = varies, but they're essentially the "3rd party" model. > The reason to keep discussing this in stir is to emphasize that the mecha= nism may need to carry some other data, like the assurance on the name, in = addition to what we're already discussing. That's a good point. One of the things we talked about originally was that a valid calling numbe= r was a precursor to calling name, because the name lookup is based on the = calling number for the key. So I think for the current LIDB/CNAM models th= e currently-proposed STIR in-band data is sufficient (or at least I was thi= nking that way when I wrote the draft-IKES mechanism). Regardless, my concern is I can easily foresee a calling name discussion kn= ocking us off-the-tracks very quickly. For example I expect the feature-cr= eep to begin with including various other forms of name identifiers, such a= s email or social-site-based names, and then getting into the need for an I= dP model, SSO/SAML/OpenID, OAuth, etc. Or we start debating how to disting= uish legitimate financial banks from blood banks and sperm banks; or how us= ers receiving just the string "Fidelity" disambiguate when they get calls f= rom: Fidelity Investments, Fidelity National Financial, Fidelity National I= nformation Services, USS Fidelity, Fidelity Records, Fidelity IL, Fidelity = MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fidelity Township= NJ. (all legal, separate entities in the US) I don't really know how to prevent such ratholes, but maybe we need a separ= ate mailing list for the name discussions (i.e. for a research/design-team)= to separate that stuff out and keep this one focused on the charter's scop= e? -hadriel --_000_2B0F677F0B95454297753F58D4A07FA3012AF557CEFHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

From: stir-bounces@= ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
= Sent: Friday, August 23, 2013 2:25 PM
To: Hadriel KaplanCc: stir@ietf.org
Subject: Re: [stir] Textual caller ID = (was Re: Moving from BOF to Charter, Early Homework)

<= p class=3DMsoNormal> 

The only= think we have now is a way for the termination end to use an alternate sou= rce of names.  In the scheme we're discussing, the primary mechanism D= OES NOT use a database queried by TN at the termination, except when it doe= sn't like the trustworthlyness of the originator's validation service, or w= hen there is no name, or no validation - i.e. fall back.

 

= The primary mechanism would be to use the display name in SIP, with a new v= alidation thingie in the stir signature, from a trusted 3rd party (hopefull= y one of only a few of them).  We don't do that today. 

 

Let me emphasize:

&nb= sp;

All I want out of stir is a wa= y to extend the signature to cover whatever we come up with.  That &qu= ot;whatever" can be done in a recharter of stir, later, or it could be= done in a separate WG, as long as we can extend the signature to cover oth= er stuff.

 

I think another mail list is a good idea,= but that means we have to come up with another acronym!

 

Brian

 =

 

On Fri, Aug 23, 20= 13 at 2:44 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:


On Aug 23, 2= 013, at 1:22 PM, Brian Rosen <br@br= ianrosen.net> wrote:

> The idea is that you get a 3rd part= y to provide the level of assurance, hoping that the number of such service= s would be small and thus the trustworhlyness of them being understood wide= ly.  The termination end can decide if it trusts that third party, and= , if necessary, use an alternative service if it doesn't.

We have that already today: just in the USA there a= re over a dozen LIDB providers, and even more CNAM DB providers.  The = validity of the data in them varies, but they're essentially the "3rd = party" model.



> The reason to keep discussing this in stir is t= o emphasize that the mechanism may need to carry some other data, like the = assurance on the name, in addition to what we're already discussing.

That's a = good point.

One of the things we talked about originally was that a = valid calling number was a precursor to calling name, because the name look= up is based on the calling number for the key.  So I think for the cur= rent LIDB/CNAM models the currently-proposed STIR in-band data is sufficien= t (or at least I was thinking that way when I wrote the draft-IKES mechanis= m).

Regardless, my concern is I can easily foresee a calling name di= scussion knocking us off-the-tracks very quickly.  For example I expec= t the feature-creep to begin with including various other forms of name ide= ntifiers, such as email or social-site-based names, and then getting into t= he need for an IdP model, SSO/SAML/OpenID, OAuth, etc.  Or we start de= bating how to distinguish legitimate financial banks from blood banks and s= perm banks; or how users receiving just the string "Fidelity" dis= ambiguate when they get calls from: Fidelity Investments, Fidelity National= Financial, Fidelity National Information Services, USS Fidelity, Fidelity = Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fide= lity WFID, or Fidelity Township NJ. (all legal, separate entities in the US= )

I don't really know how to prevent such ratholes, but maybe we nee= d a separate mailing list for the name discussions (i.e. for a research/des= ign-team) to separate that stuff out and keep this one focused on the chart= er's scope?

-hadr= iel

 

= --_000_2B0F677F0B95454297753F58D4A07FA3012AF557CEFHDP1LUMXC7V3_-- From michael.hammer@yaanatech.com Fri Aug 23 12:55:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6636F11E8106 for ; Fri, 23 Aug 2013 12:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1Jj3j-yFapf for ; Fri, 23 Aug 2013 12:55:15 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id E446C21F997D for ; Fri, 23 Aug 2013 12:55:12 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 23 Aug 2013 12:55:10 -0700 From: Michael Hammer To: "br@brianrosen.net" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: AQHOoDZ3LXaHJCyxZUG8W1HRL/Rc5JmjNImA Date: Fri, 23 Aug 2013 19:55:10 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2C45B@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.152] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0195_01CEA019.24BDAD00" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 19:55:20 -0000 ------=_NextPart_000_0195_01CEA019.24BDAD00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0196_01CEA019.24BDAD00" ------=_NextPart_001_0196_01CEA019.24BDAD00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Brian, Your fatal flaw is that the trust of the signature must be based in the authority over the thing to be signed. With E.164 numbers we have some hope of achieving that; with all others probably no chance in hell to do so. Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, August 23, 2013 3:25 PM To: Hadriel Kaplan Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) The only think we have now is a way for the termination end to use an alternate source of names. In the scheme we're discussing, the primary mechanism DOES NOT use a database queried by TN at the termination, except when it doesn't like the trustworthlyness of the originator's validation service, or when there is no name, or no validation - i.e. fall back. The primary mechanism would be to use the display name in SIP, with a new validation thingie in the stir signature, from a trusted 3rd party (hopefully one of only a few of them). We don't do that today. Let me emphasize: All I want out of stir is a way to extend the signature to cover whatever we come up with. That "whatever" can be done in a recharter of stir, later, or it could be done in a separate WG, as long as we can extend the signature to cover other stuff. I think another mail list is a good idea, but that means we have to come up with another acronym! Brian On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan wrote: On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote: > The idea is that you get a 3rd party to provide the level of assurance, hoping that the number of such services would be small and thus the trustworhlyness of them being understood widely. The termination end can decide if it trusts that third party, and, if necessary, use an alternative service if it doesn't. We have that already today: just in the USA there are over a dozen LIDB providers, and even more CNAM DB providers. The validity of the data in them varies, but they're essentially the "3rd party" model. > The reason to keep discussing this in stir is to emphasize that the mechanism may need to carry some other data, like the assurance on the name, in addition to what we're already discussing. That's a good point. One of the things we talked about originally was that a valid calling number was a precursor to calling name, because the name lookup is based on the calling number for the key. So I think for the current LIDB/CNAM models the currently-proposed STIR in-band data is sufficient (or at least I was thinking that way when I wrote the draft-IKES mechanism). Regardless, my concern is I can easily foresee a calling name discussion knocking us off-the-tracks very quickly. For example I expect the feature-creep to begin with including various other forms of name identifiers, such as email or social-site-based names, and then getting into the need for an IdP model, SSO/SAML/OpenID, OAuth, etc. Or we start debating how to distinguish legitimate financial banks from blood banks and sperm banks; or how users receiving just the string "Fidelity" disambiguate when they get calls from: Fidelity Investments, Fidelity National Financial, Fidelity National Information Services, USS Fidelity, Fidelity Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all legal, separate entities in the US) I don't really know how to prevent such ratholes, but maybe we need a separate mailing list for the name discussions (i.e. for a research/design-team) to separate that stuff out and keep this one focused on the charter's scope? -hadriel ------=_NextPart_001_0196_01CEA019.24BDAD00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,

 

Your fatal flaw is that the trust of the signature must be based in = the authority over the thing to be signed.

With E.164 numbers we have some hope of achieving that; with all = others probably no chance in hell to do so.

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Brian Rosen
Sent: Friday, August 23, 2013 3:25 = PM
To: Hadriel Kaplan
Cc: = stir@ietf.org
Subject: Re: [stir] Textual caller ID (was Re: = Moving from BOF to Charter, Early Homework)

 

The = only think we have now is a way for the termination end to use an = alternate source of names.  In the scheme we're discussing, the = primary mechanism DOES NOT use a database queried by TN at the = termination, except when it doesn't like the trustworthlyness of the = originator's validation service, or when there is no name, or no = validation - i.e. fall back.

 

The primary mechanism would be to use the display name = in SIP, with a new validation thingie in the stir signature, from a = trusted 3rd party (hopefully one of only a few of them).  We don't = do that today. 

 

Let me emphasize:

 

All I want out of stir is a way to extend the = signature to cover whatever we come up with.  That = "whatever" can be done in a recharter of stir, later, or it = could be done in a separate WG, as long as we can extend the signature = to cover other stuff.

 

I = think another mail list is a good idea, but that means we have to come = up with another acronym!

 

Brian

 

 

On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> = wrote:


On Aug 23, 2013, at 1:22 PM, Brian = Rosen <br@brianrosen.net> = wrote:

> The idea is that you get a 3rd party to provide the = level of assurance, hoping that the number of such services would be = small and thus the trustworhlyness of them being understood widely. =  The termination end can decide if it trusts that third party, and, = if necessary, use an alternative service if it = doesn't.

We have that already = today: just in the USA there are over a dozen LIDB providers, and even = more CNAM DB providers.  The validity of the data in them varies, = but they're essentially the "3rd party" = model.



> The reason to keep = discussing this in stir is to emphasize that the mechanism may need to = carry some other data, like the assurance on the name, in addition to = what we're already discussing.

That's a good point.

One of the = things we talked about originally was that a valid calling number was a = precursor to calling name, because the name lookup is based on the = calling number for the key.  So I think for the current LIDB/CNAM = models the currently-proposed STIR in-band data is sufficient (or at = least I was thinking that way when I wrote the draft-IKES = mechanism).

Regardless, my concern is I can easily foresee a = calling name discussion knocking us off-the-tracks very quickly. =  For example I expect the feature-creep to begin with including = various other forms of name identifiers, such as email or = social-site-based names, and then getting into the need for an IdP = model, SSO/SAML/OpenID, OAuth, etc.  Or we start debating how to = distinguish legitimate financial banks from blood banks and sperm banks; = or how users receiving just the string "Fidelity" disambiguate = when they get calls from: Fidelity Investments, Fidelity National = Financial, Fidelity National Information Services, USS Fidelity, = Fidelity Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity = Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all legal, separate = entities in the US)

I don't really know how to prevent such = ratholes, but maybe we need a separate mailing list for the name = discussions (i.e. for a research/design-team) to separate that stuff out = and keep this one focused on the charter's scope?

-hadriel

 

------=_NextPart_001_0196_01CEA019.24BDAD00-- ------=_NextPart_000_0195_01CEA019.24BDAD00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgy MzE5NTUwOVowIwYJKoZIhvcNAQkEMRYEFBRmwyoVCB26IO4TXw/Ag2RCkIdhMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAUr+n4qxTCsDztk6ABKED06Nu96nhdoWnR4NmH+/L Qwz1mIod8o4kGU88AypxakLUl9FSFzRSNkRl9TlfBDOKys6pspGvedEtavPRCmzdWTbEvvTtUtRW zgGRs/ec2yRkRFNpIPVVKIYT4434Xorrfb/hD9x4q2+GlI/nM2qitrgh6v5rp+KvXSBG0cZwKFPN Z4cTuBOFANDSp/t+sHPCtuCrQAqUInIy4SGN2/hyw/bjB+5nIO6xNyYKot9UfxVwoY4bpcksMJih eCDZ4vKHgGA/dX78e7xbUS4KOufB/L/uYWUdJfIHox0zNdt1dsJ27Ru6VBXE0Ehk6ATGmvZAAwAA AAAAAA== ------=_NextPart_000_0195_01CEA019.24BDAD00-- From michael.hammer@yaanatech.com Fri Aug 23 12:58:05 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A896421F9E39 for ; Fri, 23 Aug 2013 12:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po-iKp1gzQEQ for ; Fri, 23 Aug 2013 12:58:00 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6786E21F9DFC for ; Fri, 23 Aug 2013 12:58:00 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 23 Aug 2013 12:58:00 -0700 From: Michael Hammer To: Michael Hammer , "br@brianrosen.net" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: AQHOoDZ3LXaHJCyxZUG8W1HRL/Rc5JmjNImAgAABC2A= Date: Fri, 23 Aug 2013 19:57:59 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2C47B@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC2C45B@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2C45B@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.152] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_019D_01CEA019.8991BFA0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 19:58:05 -0000 ------=_NextPart_000_019D_01CEA019.8991BFA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_019E_01CEA019.8991BFA0" ------=_NextPart_001_019E_01CEA019.8991BFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit p.s. maybe something that is SHAKEN but not STIR'd. J Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Friday, August 23, 2013 3:55 PM To: br@brianrosen.net; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Brian, Your fatal flaw is that the trust of the signature must be based in the authority over the thing to be signed. With E.164 numbers we have some hope of achieving that; with all others probably no chance in hell to do so. Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, August 23, 2013 3:25 PM To: Hadriel Kaplan Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) The only think we have now is a way for the termination end to use an alternate source of names. In the scheme we're discussing, the primary mechanism DOES NOT use a database queried by TN at the termination, except when it doesn't like the trustworthlyness of the originator's validation service, or when there is no name, or no validation - i.e. fall back. The primary mechanism would be to use the display name in SIP, with a new validation thingie in the stir signature, from a trusted 3rd party (hopefully one of only a few of them). We don't do that today. Let me emphasize: All I want out of stir is a way to extend the signature to cover whatever we come up with. That "whatever" can be done in a recharter of stir, later, or it could be done in a separate WG, as long as we can extend the signature to cover other stuff. I think another mail list is a good idea, but that means we have to come up with another acronym! Brian On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan wrote: On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote: > The idea is that you get a 3rd party to provide the level of assurance, hoping that the number of such services would be small and thus the trustworhlyness of them being understood widely. The termination end can decide if it trusts that third party, and, if necessary, use an alternative service if it doesn't. We have that already today: just in the USA there are over a dozen LIDB providers, and even more CNAM DB providers. The validity of the data in them varies, but they're essentially the "3rd party" model. > The reason to keep discussing this in stir is to emphasize that the mechanism may need to carry some other data, like the assurance on the name, in addition to what we're already discussing. That's a good point. One of the things we talked about originally was that a valid calling number was a precursor to calling name, because the name lookup is based on the calling number for the key. So I think for the current LIDB/CNAM models the currently-proposed STIR in-band data is sufficient (or at least I was thinking that way when I wrote the draft-IKES mechanism). Regardless, my concern is I can easily foresee a calling name discussion knocking us off-the-tracks very quickly. For example I expect the feature-creep to begin with including various other forms of name identifiers, such as email or social-site-based names, and then getting into the need for an IdP model, SSO/SAML/OpenID, OAuth, etc. Or we start debating how to distinguish legitimate financial banks from blood banks and sperm banks; or how users receiving just the string "Fidelity" disambiguate when they get calls from: Fidelity Investments, Fidelity National Financial, Fidelity National Information Services, USS Fidelity, Fidelity Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all legal, separate entities in the US) I don't really know how to prevent such ratholes, but maybe we need a separate mailing list for the name discussions (i.e. for a research/design-team) to separate that stuff out and keep this one focused on the charter's scope? -hadriel ------=_NextPart_001_019E_01CEA019.8991BFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

p.s.  maybe something that is SHAKEN but not STIR’d.  = J

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Michael Hammer
Sent: Friday, August 23, 2013 3:55 = PM
To: br@brianrosen.net; = hadriel.kaplan@oracle.com
Cc: stir@ietf.org
Subject: = Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early = Homework)

 

Brian,

 

Your fatal flaw is that the trust of the signature must be based in = the authority over the thing to be signed.

With E.164 numbers we have some hope of achieving that; with all = others probably no chance in hell to do so.

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.= org] On Behalf Of Brian Rosen
Sent: Friday, August = 23, 2013 3:25 PM
To: Hadriel Kaplan
Cc: stir@ietf.org
Subject: Re: = [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early = Homework)

 

The = only think we have now is a way for the termination end to use an = alternate source of names.  In the scheme we're discussing, the = primary mechanism DOES NOT use a database queried by TN at the = termination, except when it doesn't like the trustworthlyness of the = originator's validation service, or when there is no name, or no = validation - i.e. fall back.

 

The primary mechanism would be to use the display name = in SIP, with a new validation thingie in the stir signature, from a = trusted 3rd party (hopefully one of only a few of them).  We don't = do that today. 

 

Let me emphasize:

 

All I want out of stir is a way to extend the = signature to cover whatever we come up with.  That = "whatever" can be done in a recharter of stir, later, or it = could be done in a separate WG, as long as we can extend the signature = to cover other stuff.

 

I = think another mail list is a good idea, but that means we have to come = up with another acronym!

 

Brian

 

 

On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> = wrote:


On Aug 23, 2013, at 1:22 PM, Brian = Rosen <br@brianrosen.net> = wrote:

> The idea is that you get a 3rd party to provide the = level of assurance, hoping that the number of such services would be = small and thus the trustworhlyness of them being understood widely. =  The termination end can decide if it trusts that third party, and, = if necessary, use an alternative service if it = doesn't.

We have that already = today: just in the USA there are over a dozen LIDB providers, and even = more CNAM DB providers.  The validity of the data in them varies, = but they're essentially the "3rd party" = model.



> The reason to keep = discussing this in stir is to emphasize that the mechanism may need to = carry some other data, like the assurance on the name, in addition to = what we're already discussing.

That's a good point.

One of the = things we talked about originally was that a valid calling number was a = precursor to calling name, because the name lookup is based on the = calling number for the key.  So I think for the current LIDB/CNAM = models the currently-proposed STIR in-band data is sufficient (or at = least I was thinking that way when I wrote the draft-IKES = mechanism).

Regardless, my concern is I can easily foresee a = calling name discussion knocking us off-the-tracks very quickly. =  For example I expect the feature-creep to begin with including = various other forms of name identifiers, such as email or = social-site-based names, and then getting into the need for an IdP = model, SSO/SAML/OpenID, OAuth, etc.  Or we start debating how to = distinguish legitimate financial banks from blood banks and sperm banks; = or how users receiving just the string "Fidelity" disambiguate = when they get calls from: Fidelity Investments, Fidelity National = Financial, Fidelity National Information Services, USS Fidelity, = Fidelity Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity = Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all legal, separate = entities in the US)

I don't really know how to prevent such = ratholes, but maybe we need a separate mailing list for the name = discussions (i.e. for a research/design-team) to separate that stuff out = and keep this one focused on the charter's scope?

-hadriel

 

------=_NextPart_001_019E_01CEA019.8991BFA0-- ------=_NextPart_000_019D_01CEA019.8991BFA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgy MzE5NTc1OFowIwYJKoZIhvcNAQkEMRYEFOHCQ38CLXiv5eZmYlDn+TCyuruPMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAcSQ0X6mQ4AoHOklvPpcP/EF6AxExqQP3OIYaS7rf LFaUPYts+1GHNx9i6CKQw5WBm8LxjqPavn1lhUTCJhGZODF5xsqEl9VsrS9+m8A2q5hUi84Bk8oP 3pEJAA0Gf97yFmkjpMQsa4+K4+aV4gX3oDZSgSoF6DOzL8TKjsjQ7VhqDU+CScvZ3ou6EI77O7WC WTsgOimnLQE3zakAADNljp4BI/4mW7IW0A9hzpil0B8eQblQLMlS2znrTIJ/hZRWC/M1Im1bYXt/ VI8m2bDQj6vEDqeCNVacmwkSfNDGwlt03kyInflflk1wj9g6qgoOQ4E6WxVusQ+gDD4iZ+yNhgAA AAAAAA== ------=_NextPart_000_019D_01CEA019.8991BFA0-- From richard@shockey.us Fri Aug 23 13:20:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35AA11E8209 for ; Fri, 23 Aug 2013 13:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.144 X-Spam-Level: X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPyo9l6rgM-0 for ; Fri, 23 Aug 2013 13:20:34 -0700 (PDT) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 604B511E81FB for ; Fri, 23 Aug 2013 13:20:34 -0700 (PDT) Received: (qmail 8646 invoked by uid 0); 23 Aug 2013 20:20:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.mail.unifiedlayer.com with SMTP; 23 Aug 2013 20:20:09 -0000 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:Date:Subject:In-Reply-To:References:Cc:To:From; bh=l0rsIMEgXHLphJ4I/+g97vZAPunHpPSiw6PHt9yT5AY=; b=RXJNzf9MLFI7dMBvnPNMqW8LgP8QRK1LagoYyG3RsUQZE0sY7n+jh5uH2o68fYCbY0DqDWw2wIW6phi47s4RgavWWSUb5EM3Q2ID7O5B7TncLWC1oVBZ9LGA9pqD23AA; Received: from [71.114.100.16] (port=55079 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VCxq4-0005dl-EP; Fri, 23 Aug 2013 14:20:08 -0600 From: "Richard Shockey" To: "'Brian Rosen'" , "'Hadriel Kaplan'" References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> In-Reply-To: Date: Fri, 23 Aug 2013 16:20:04 -0400 Message-ID: <004301cea03e$28fa9390$7aefbab0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01CEA01C.A1E98FD0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJoETO1yDlWf8bawuK/DoJvnQdzbQIrf0IYApK+4osBoqM54gKdsM08AVaoXs8B+LroAgKzUOH9AhRg0HsBpK4tkQJv7Gfkl8cGntA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 20:20:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0044_01CEA01C.A1E98FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The primary mechanism would be to use the display name in SIP, with a new validation thingie in the stir signature, from a trusted 3rd party (hopefully one of only a few of them). We don't do that today. Let me emphasize: All I want out of stir is a way to extend the signature to cover whatever we come up with. That "whatever" can be done in a recharter of stir, later, or it could be done in a separate WG, as long as we can extend the signature to cover other stuff. I think another mail list is a good idea, but that means we have to come up with another acronym! [RS> ] [RS> ] WARNING WARNING DANGER WILL ROBINSON!! OCEAN BOILING ALERT! Its perfectly reasonable to postulate that the signing can ultimately extend cover "other things". That was Richard Barnes's excellent point. We dont have an approved charter yet and we're talking extensions? Brian ------=_NextPart_000_0044_01CEA01C.A1E98FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The primary mechanism would be to use the display name = in SIP, with a new validation thingie in the stir signature, from a = trusted 3rd party (hopefully one of only a few of them).  We don't = do that today. 

 

Let me emphasize:

 

All I want out of stir is a way to extend the = signature to cover whatever we come up with.  That = "whatever" can be done in a recharter of stir, later, or it = could be done in a separate WG, as long as we can extend the signature = to cover other stuff.

 

I = think another mail list is a good idea, but that means we have to come = up with another acronym!

[RS> ]

[RS> ] WARNING WARNING DANGER WILL ROBINSON!!  OCEAN BOILING = ALERT!  Its perfectly reasonable to postulate that the signing can = ultimately extend cover “other things”. That was Richard = Barnes’s excellent point. We dont have an approved charter yet and = we’re talking extensions?

 

 

Brian

 

------=_NextPart_000_0044_01CEA01C.A1E98FD0-- From richard@shockey.us Fri Aug 23 13:22:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50DC21F9CF8 for ; Fri, 23 Aug 2013 13:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XzKu8bWt0Sj for ; Fri, 23 Aug 2013 13:22:48 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 2EC1721F9D7E for ; Fri, 23 Aug 2013 13:22:48 -0700 (PDT) Received: (qmail 31641 invoked by uid 0); 23 Aug 2013 20:22:24 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.mail.unifiedlayer.com with SMTP; 23 Aug 2013 20:22:24 -0000 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:Date:Subject:In-Reply-To:References:Cc:To:From; bh=uzULsPMO9LZeW+bIcm9PdRtB0OZdDzUKEfhy2wJTXZY=; b=KqgucFCIm+Gv2O7FxHPfra+gRWhWZDdhGfrxz7lsLOtBo++9BDYjurDWOgj3fCDY0SBjHngZ++I8RtRJmlwynubwl0A9hzaz1iprEYbvmv1fyVS5l5ggK2+JvhGOU35W; Received: from [71.114.100.16] (port=55086 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VCxsG-0007ci-6t; Fri, 23 Aug 2013 14:22:24 -0600 From: "Richard Shockey" To: "'Michael Hammer'" References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC2C45B@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC2C47B@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2C47B@EX2K10MB1.corp.yaanatech.com> Date: Fri, 23 Aug 2013 16:22:22 -0400 Message-ID: <004801cea03e$79e72110$6db56330$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CEA01C.F2D9C6D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJoETO1yDlWf8bawuK/DoJvnQdzbQIrf0IYApK+4osBoqM54gKdsM08AVaoXs8B+LroAgKzUOH9AhRg0HsBpK4tkQJv7GfkAlLtal4DnluTYJeXfeCA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 20:22:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0049_01CEA01C.F2D9C6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit VODKA . MARTINI has been used. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Friday, August 23, 2013 3:58 PM To: Michael Hammer; br@brianrosen.net; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) p.s. maybe something that is SHAKEN but not STIR'd. :) Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Friday, August 23, 2013 3:55 PM To: br@brianrosen.net ; hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Brian, Your fatal flaw is that the trust of the signature must be based in the authority over the thing to be signed. With E.164 numbers we have some hope of achieving that; with all others probably no chance in hell to do so. Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, August 23, 2013 3:25 PM To: Hadriel Kaplan Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) The only think we have now is a way for the termination end to use an alternate source of names. In the scheme we're discussing, the primary mechanism DOES NOT use a database queried by TN at the termination, except when it doesn't like the trustworthlyness of the originator's validation service, or when there is no name, or no validation - i.e. fall back. The primary mechanism would be to use the display name in SIP, with a new validation thingie in the stir signature, from a trusted 3rd party (hopefully one of only a few of them). We don't do that today. Let me emphasize: All I want out of stir is a way to extend the signature to cover whatever we come up with. That "whatever" can be done in a recharter of stir, later, or it could be done in a separate WG, as long as we can extend the signature to cover other stuff. I think another mail list is a good idea, but that means we have to come up with another acronym! Brian On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan > wrote: On Aug 23, 2013, at 1:22 PM, Brian Rosen > wrote: > The idea is that you get a 3rd party to provide the level of assurance, hoping that the number of such services would be small and thus the trustworhlyness of them being understood widely. The termination end can decide if it trusts that third party, and, if necessary, use an alternative service if it doesn't. We have that already today: just in the USA there are over a dozen LIDB providers, and even more CNAM DB providers. The validity of the data in them varies, but they're essentially the "3rd party" model. > The reason to keep discussing this in stir is to emphasize that the mechanism may need to carry some other data, like the assurance on the name, in addition to what we're already discussing. That's a good point. One of the things we talked about originally was that a valid calling number was a precursor to calling name, because the name lookup is based on the calling number for the key. So I think for the current LIDB/CNAM models the currently-proposed STIR in-band data is sufficient (or at least I was thinking that way when I wrote the draft-IKES mechanism). Regardless, my concern is I can easily foresee a calling name discussion knocking us off-the-tracks very quickly. For example I expect the feature-creep to begin with including various other forms of name identifiers, such as email or social-site-based names, and then getting into the need for an IdP model, SSO/SAML/OpenID, OAuth, etc. Or we start debating how to distinguish legitimate financial banks from blood banks and sperm banks; or how users receiving just the string "Fidelity" disambiguate when they get calls from: Fidelity Investments, Fidelity National Financial, Fidelity National Information Services, USS Fidelity, Fidelity Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all legal, separate entities in the US) I don't really know how to prevent such ratholes, but maybe we need a separate mailing list for the name discussions (i.e. for a research/design-team) to separate that stuff out and keep this one focused on the charter's scope? -hadriel ------=_NextPart_000_0049_01CEA01C.F2D9C6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

VODKA …  MARTINI has been used.

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Michael Hammer
Sent: Friday, August 23, 2013 3:58 = PM
To: Michael Hammer; br@brianrosen.net; = hadriel.kaplan@oracle.com
Cc: stir@ietf.org
Subject: = Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early = Homework)

 

p.s.  maybe something that is SHAKEN but not STIR’d.  = J

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On Behalf Of Michael Hammer
Sent: Friday, August 23, = 2013 3:55 PM
To: br@brianrosen.net; hadriel.kaplan@oracle.comCc: stir@ietf.org
Subject: Re: = [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early = Homework)

 

Brian,

 

Your fatal flaw is that the trust of the signature must be based in = the authority over the thing to be signed.

With E.164 numbers we have some hope of achieving that; with all = others probably no chance in hell to do so.

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.= org] On Behalf Of Brian Rosen
Sent: Friday, August = 23, 2013 3:25 PM
To: Hadriel Kaplan
Cc: stir@ietf.org
Subject: Re: = [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early = Homework)

 

The = only think we have now is a way for the termination end to use an = alternate source of names.  In the scheme we're discussing, the = primary mechanism DOES NOT use a database queried by TN at the = termination, except when it doesn't like the trustworthlyness of the = originator's validation service, or when there is no name, or no = validation - i.e. fall back.

 

The primary mechanism would be to use the display name = in SIP, with a new validation thingie in the stir signature, from a = trusted 3rd party (hopefully one of only a few of them).  We don't = do that today. 

 

Let me emphasize:

 

All I want out of stir is a way to extend the = signature to cover whatever we come up with.  That = "whatever" can be done in a recharter of stir, later, or it = could be done in a separate WG, as long as we can extend the signature = to cover other stuff.

 

I = think another mail list is a good idea, but that means we have to come = up with another acronym!

 

Brian

 

 

On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> = wrote:


On Aug 23, 2013, at 1:22 PM, Brian = Rosen <br@brianrosen.net> = wrote:

> The idea is that you get a 3rd party to provide the = level of assurance, hoping that the number of such services would be = small and thus the trustworhlyness of them being understood widely. =  The termination end can decide if it trusts that third party, and, = if necessary, use an alternative service if it = doesn't.

We have that already = today: just in the USA there are over a dozen LIDB providers, and even = more CNAM DB providers.  The validity of the data in them varies, = but they're essentially the "3rd party" = model.



> The reason to keep = discussing this in stir is to emphasize that the mechanism may need to = carry some other data, like the assurance on the name, in addition to = what we're already discussing.

That's a good point.

One of the = things we talked about originally was that a valid calling number was a = precursor to calling name, because the name lookup is based on the = calling number for the key.  So I think for the current LIDB/CNAM = models the currently-proposed STIR in-band data is sufficient (or at = least I was thinking that way when I wrote the draft-IKES = mechanism).

Regardless, my concern is I can easily foresee a = calling name discussion knocking us off-the-tracks very quickly. =  For example I expect the feature-creep to begin with including = various other forms of name identifiers, such as email or = social-site-based names, and then getting into the need for an IdP = model, SSO/SAML/OpenID, OAuth, etc.  Or we start debating how to = distinguish legitimate financial banks from blood banks and sperm banks; = or how users receiving just the string "Fidelity" disambiguate = when they get calls from: Fidelity Investments, Fidelity National = Financial, Fidelity National Information Services, USS Fidelity, = Fidelity Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity = Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all legal, separate = entities in the US)

I don't really know how to prevent such = ratholes, but maybe we need a separate mailing list for the name = discussions (i.e. for a research/design-team) to separate that stuff out = and keep this one focused on the charter's scope?

-hadriel

 

------=_NextPart_000_0049_01CEA01C.F2D9C6D0-- From hadriel.kaplan@oracle.com Fri Aug 23 13:33:54 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A813E11E8120 for ; Fri, 23 Aug 2013 13:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJiZBFR+jbXl for ; Fri, 23 Aug 2013 13:33:48 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 57A1511E8108 for ; Fri, 23 Aug 2013 13:33:42 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7NKXe3E028329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Aug 2013 20:33:40 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7NKXdAg012924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 20:33:40 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7NKXdGJ001590; Fri, 23 Aug 2013 20:33:39 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Aug 2013 13:33:39 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 23 Aug 2013 16:33:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <038413CA-EC32-43F6-941B-9444CD2DD4CD@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 20:33:54 -0000 On Aug 23, 2013, at 3:24 PM, Brian Rosen wrote: > The only think we have now is a way for the termination end to use an = alternate source of names. In the scheme we're discussing, the primary = mechanism DOES NOT use a database queried by TN at the termination, = except when it doesn't like the trustworthlyness of the originator's = validation service, or when there is no name, or no validation - i.e. = fall back. I'm not sure which "scheme we're discussing" you're referring to: the = calling number validation scheme, or the calling name validation scheme? = For the calling number validation scheme, it does use a database = queried by the TN at the termination: the one to retrieve the public key = or cert from. CNAM likewise queries a database by the TN, at the = termination. =46rom the verifier's perspective, they could either be = the exact same physical database being queried, or separate physical = databases. Or the public-key database entry could identify which 3rd = party identity provider to go query for calling name, but that = subsequent query could still be made using the validated TN, or a hash = of one, for example. > The primary mechanism would be to use the display name in SIP, with a = new validation thingie in the stir signature, from a trusted 3rd party = (hopefully one of only a few of them). We don't do that today.=20 That's presuming a particular solution, and I don't know what the = details of it are so I'm not sure I follow you. If the solution you're = thinking of is to use the same private key to also sign the display-name = (ie, include the display-name in the STIR signature), I don't think you = actually need to do that. If the solution you're thinking of is to use = a separate private-key to sign the display-name, that's a bigger deal. > Let me emphasize: > All I want out of stir is a way to extend the signature to cover = whatever we come up with. That "whatever" can be done in a recharter of = stir, later, or it could be done in a separate WG, as long as we can = extend the signature to cover other stuff. For me, it depends on how that would be accomplished. =46rom a protocol = spec perspective sure, we could always extend a published RFC in the = future, so long as there's ABNF extensibility and so on. But presumably = you'd want some way for the initial STIR work to be forwards-compatible = with that extension, such that the initial STIR signature continues to = "work" even if it reaches a verifier that doesn't support a new calling = name verification thing. Right? > I think another mail list is a good idea, but that means we have to = come up with another acronym! haven't thought about it much. Here're some off the top of my head: Secure Caller-Associated Name - SCAN Reputable Identity Name Greeting - RING (which would make for a = STIRRING solution) Calling Name Identity Communication - CNIC (pronounced Scenic) Stir-Transported Reputable Identity Name Generator - STRING Assured Source Caller Identity Information - ASCII ;) -hadriel From pkyzivat@alum.mit.edu Fri Aug 23 13:43:27 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E29911E8109 for ; Fri, 23 Aug 2013 13:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ostP0z4axSG for ; Fri, 23 Aug 2013 13:43:21 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id AAEA911E8108 for ; Fri, 23 Aug 2013 13:43:21 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta09.westchester.pa.mail.comcast.net with comcast id GKEf1m0010cZkys59LjMXz; Fri, 23 Aug 2013 20:43:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id GLjM1m0083ZTu2S3WLjM6E; Fri, 23 Aug 2013 20:43:21 +0000 Message-ID: <5217C968.2070909@alum.mit.edu> Date: Fri, 23 Aug 2013 16:43:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC2C45B@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC2C47B@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC2C47B@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377290601; bh=B+6aSYuOLs5kMAa9SyxXyul1zTUS3qurjF1G9jzSaUs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZDajAu5+4AG/dI13Oox+7I+j+1SSw2WrHRZvacUw6jifhKkXm0unym/F6y4bzwWUt 447V80lbKM4YnJhrLnk2x3JFmuPTxn4RmDR08S5K/hqXsgtMa6XZrD0vV2fqGLI9m7 WaIEQFA2Ts0LIaHce/bnsTwsKlDMZIuCeq74ukP+XGITAFB4GNoPe9s7lQngv1MFN6 oatG8oT1vNi3pC2ax08GghZHVT4MIhd3e2Hiu4lEZR3adKD+nRw1lAONbN2tS+h/Vy ttc8Eu5/nLndfNd583sS7KEEI2rLvXKk95a1UJ97u3etYWf93PbySI5HMqfUTdr2Cq B91rRX6IRrf8g== Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 20:43:27 -0000 On 8/23/13 3:57 PM, Michael Hammer wrote: > p.s. maybe something that is SHAKEN but not STIR’d. J But actually we expect something that is both STIRed *and* SHAKEN. From pkyzivat@alum.mit.edu Fri Aug 23 13:50:26 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ECA11E8123 for ; Fri, 23 Aug 2013 13:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw5PxVyYLRr8 for ; Fri, 23 Aug 2013 13:50:21 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 1427111E8177 for ; Fri, 23 Aug 2013 13:50:20 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id GCvG1m00R0bG4ec55LqBAJ; Fri, 23 Aug 2013 20:50:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id GLqA1m00y3ZTu2S3PLqBZt; Fri, 23 Aug 2013 20:50:11 +0000 Message-ID: <5217CB01.6070708@alum.mit.edu> Date: Fri, 23 Aug 2013 16:50:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377291011; bh=8840VS3bAqJkohrr0Oa5HXxJSW5IfYD9QFIHlJlJxFo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bvn/xlD1zPsbHU4jDimPId19Hs7vwMLJnIAS2Sd3Pk1SgPk3RZNxSGQAsNlBnJWFn 0ZFqE9Pfo182F1hDYl87WoqjrlE3hRN7wcjpxYpMTGLww3XAeS3KtJMTQ1E1hCcl08 ByPUcRh+MQaCM/8cpvi3G94jDQ5QZ5xMr2XR51WBWNrBlxll2d8ByICPNKOTk1iEOK MQz7r2qRMo2K9k3tCPXaGjQLDdsxwRR9I83dicYlfqmoBTYibEVz1ji8IzRLYv9Vfr l8ZZWYiwNqjCuzUQTq5xitmFNa1d+cUMHpZTvICQBBa+SZk40rN2xbwqaHD4NRiZsD F5Iaw/USOkGUg== Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 20:50:26 -0000 So this will give the callee, at most: - the E.164 of the caller, and a signature by somebody vouching for it - a name vouched for by the same signer And with the delegation being proposed, the signer may be the assignee of the specific number. (E.g., the doctor.) The doctor can make his name be "First National Bank" if he wants to. So all this really gets you is accountability: if somebody starts using bogus names in an objectionable way then it will be possible to hold the signer responsible. This is definitely better than nothing. It may be the best we can achieve. But I doubt it is what users expect. Thanks, Paul On 8/23/13 3:24 PM, Brian Rosen wrote: > The only think we have now is a way for the termination end to use an > alternate source of names. In the scheme we're discussing, the primary > mechanism DOES NOT use a database queried by TN at the termination, > except when it doesn't like the trustworthlyness of the originator's > validation service, or when there is no name, or no validation - i.e. > fall back. > > The primary mechanism would be to use the display name in SIP, with a > new validation thingie in the stir signature, from a trusted 3rd party > (hopefully one of only a few of them). We don't do that today. > > Let me emphasize: > > All I want out of stir is a way to extend the signature to cover > whatever we come up with. That "whatever" can be done in a recharter of > stir, later, or it could be done in a separate WG, as long as we can > extend the signature to cover other stuff. > > I think another mail list is a good idea, but that means we have to come > up with another acronym! > > Brian > > > > On Fri, Aug 23, 2013 at 2:44 PM, Hadriel Kaplan > > wrote: > > > On Aug 23, 2013, at 1:22 PM, Brian Rosen > wrote: > > > The idea is that you get a 3rd party to provide the level of > assurance, hoping that the number of such services would be small > and thus the trustworhlyness of them being understood widely. The > termination end can decide if it trusts that third party, and, if > necessary, use an alternative service if it doesn't. > > We have that already today: just in the USA there are over a dozen > LIDB providers, and even more CNAM DB providers. The validity of > the data in them varies, but they're essentially the "3rd party" model. > > > > The reason to keep discussing this in stir is to emphasize that > the mechanism may need to carry some other data, like the assurance > on the name, in addition to what we're already discussing. > > That's a good point. > > One of the things we talked about originally was that a valid > calling number was a precursor to calling name, because the name > lookup is based on the calling number for the key. So I think for > the current LIDB/CNAM models the currently-proposed STIR in-band > data is sufficient (or at least I was thinking that way when I wrote > the draft-IKES mechanism). > > Regardless, my concern is I can easily foresee a calling name > discussion knocking us off-the-tracks very quickly. For example I > expect the feature-creep to begin with including various other forms > of name identifiers, such as email or social-site-based names, and > then getting into the need for an IdP model, SSO/SAML/OpenID, OAuth, > etc. Or we start debating how to distinguish legitimate financial > banks from blood banks and sperm banks; or how users receiving just > the string "Fidelity" disambiguate when they get calls from: > Fidelity Investments, Fidelity National Financial, Fidelity National > Information Services, USS Fidelity, Fidelity Records, Fidelity IL, > Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or > Fidelity Township NJ. (all legal, separate entities in the US) > > I don't really know how to prevent such ratholes, but maybe we need > a separate mailing list for the name discussions (i.e. for a > research/design-team) to separate that stuff out and keep this one > focused on the charter's scope? > > -hadriel > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From caryfitz@employees.org Fri Aug 23 15:16:56 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED3711E81AA for ; Fri, 23 Aug 2013 15:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQTRe4rBqGxo for ; Fri, 23 Aug 2013 15:16:52 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id EB84211E81C5 for ; Fri, 23 Aug 2013 15:16:51 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id C10045F87; Fri, 23 Aug 2013 15:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; s=selector1; bh=U1AX0N/ic53kKdGeVoho7YW/3mc=; b=B1FGIm7dp0EFsaG a2qeSRkySZbY3zbfbCpu6h3gWsHs6hs5T0S3/5tool8dFme/CIXuFKvF7ODF3fyf ruSxr/vVRhat2hxN31EXcGwTRfR+8Kp/bhC5sFNjkv5B0S6crQ1oPTdcZrnoY2UH ThpVb6WOxnjllJjkLRMcvR0YSRSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=references :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id:cc:from:subject:date:to; q=dns; s=selector1; b=LT5y0 mN3g+MoXqrG/GvhWXFMQOeQ91p7jLSbGU+G9yHjCfJof/JpAP3jL/Kdo76LI3EiX S2+5SC2TC4ychxRXSuIABxyaHTm9TBifz74U4gTlfP7Qh9BBNH7U95CGfjx3j7Fp XAIxRq4RVvbcRprDu6HKkihLH8q+bEQSDwr994= Received: from [192.168.1.235] (unknown [199.33.32.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: caryfitz) by banjo.employees.org (Postfix) with ESMTPSA id A86F75F80; Fri, 23 Aug 2013 15:16:49 -0700 (PDT) References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> <038413CA-EC32-43F6-941B-9444CD2DD4CD@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <038413CA-EC32-43F6-941B-9444CD2DD4CD@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <417FF422-6AC1-48D5-A96A-FA512CE54B36@employees.org> X-Mailer: iPad Mail (10B329) From: Cary FitzGerald Date: Fri, 23 Aug 2013 15:16:48 -0700 To: Hadriel Kaplan Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 22:16:57 -0000 In the end, as Hadriel points out, the question is scope. What is it? Meta (and meta-meta) data: an identity, an asserting authority (re= cognizing that the assertion that a session came from any particular PSTN nu= mber is imperfect) and a translation authority. In scope. How do I get it? In band, out of band, whatever. In scope. For the first two questions, the answers may be very similar or the same as m= echanisms that this community has been working on for 10+ years. How do my agents (UA, service providers) use it? A mechanism to query the reputation of the asserting and translatin= g authorities (including an assessment of the policy regarding asserting tha= t the number is, in fact, my "number" number, whatever that means)? In/out of scope (recognizing that now there is a meta-meta-meta dat= a issue)? Who are the authorities? Mechanisms to specify what does the name mean, who paid (whose inte= rests are represented) to have it inserted and/or translated? Out of scope? Cullen's reticence to take a call from someone who hasn't asserted t= hemselves to be someone he's talked to in the past? Out of scope. How do I translate all that information into meaning? Something that Brian, Cullen, Hadriel, Mike can use? (Also, my fri= end Howard S. Bradford-Carlson Banks, you've probably seen him around). Something my dad can use - he's a real problem because "knows" stuf= f about ANI. As a good friend of mine quoted to me: "It's not what you don= 't know that kills you. It's what you do know that just ain't so." Out of scope. The existing charter talks a lot about end user behaviors, which is sort of h= elpful as a benchmark, but is also hard to objectively assess. Cary. On Aug 23, 2013, at 1:33 PM, Hadriel Kaplan wrot= e: >=20 > On Aug 23, 2013, at 3:24 PM, Brian Rosen wrote: >=20 >> The only think we have now is a way for the termination end to use an alt= ernate source of names. In the scheme we're discussing, the primary mechani= sm DOES NOT use a database queried by TN at the termination, except when it d= oesn't like the trustworthlyness of the originator's validation service, or w= hen there is no name, or no validation - i.e. fall back. >=20 > I'm not sure which "scheme we're discussing" you're referring to: the call= ing number validation scheme, or the calling name validation scheme? For th= e calling number validation scheme, it does use a database queried by the TN= at the termination: the one to retrieve the public key or cert from. CNAM l= ikewise queries a database by the TN, at the termination. =46rom the verifi= er's perspective, they could either be the exact same physical database bein= g queried, or separate physical databases. Or the public-key database entry= could identify which 3rd party identity provider to go query for calling na= me, but that subsequent query could still be made using the validated TN, or= a hash of one, for example. >=20 >=20 >> The primary mechanism would be to use the display name in SIP, with a new= validation thingie in the stir signature, from a trusted 3rd party (hopeful= ly one of only a few of them). We don't do that today. >=20 > That's presuming a particular solution, and I don't know what the details o= f it are so I'm not sure I follow you. If the solution you're thinking of i= s to use the same private key to also sign the display-name (ie, include the= display-name in the STIR signature), I don't think you actually need to do t= hat. If the solution you're thinking of is to use a separate private-key to= sign the display-name, that's a bigger deal. >=20 >=20 >> Let me emphasize: >> All I want out of stir is a way to extend the signature to cover whatever= we come up with. That "whatever" can be done in a recharter of stir, later= , or it could be done in a separate WG, as long as we can extend the signatu= re to cover other stuff. >=20 > For me, it depends on how that would be accomplished. =46rom a protocol s= pec perspective sure, we could always extend a published RFC in the future, s= o long as there's ABNF extensibility and so on. But presumably you'd want s= ome way for the initial STIR work to be forwards-compatible with that extens= ion, such that the initial STIR signature continues to "work" even if it rea= ches a verifier that doesn't support a new calling name verification thing. = Right? >=20 >=20 >> I think another mail list is a good idea, but that means we have to come u= p with another acronym! >=20 > haven't thought about it much. Here're some off the top of my head: > Secure Caller-Associated Name - SCAN > Reputable Identity Name Greeting - RING (which would make for a STIRRING s= olution) > Calling Name Identity Communication - CNIC (pronounced Scenic) > Stir-Transported Reputable Identity Name Generator - STRING > Assured Source Caller Identity Information - ASCII ;) >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Fri Aug 23 19:12:42 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789421F99B0 for ; Fri, 23 Aug 2013 19:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUW3WbPQKOT9 for ; Fri, 23 Aug 2013 19:12:38 -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 0C61521F99A0 for ; Fri, 23 Aug 2013 19:12:37 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" , Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: AQHOoDDYSlcmU703FUC8K86PUli1V5mjc0aAgAAjGbQ= Date: Sat, 24 Aug 2013 02:12:35 +0000 References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> , <2B0F677F0B95454297753F58D4A07FA3012AF557CB@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012AF557CB@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 02:12:42 -0000 Just to clarify, as my original description obviously was lacking:=0A= =0A= I see two models, the "by-value" (display name or similar call-info informa= tion) version, along the lines that Brian has been describing, and the "by-= reference" lookup model.=0A= =0A= For the latter, my rough notion is similar to whois - the (validated) phone= number becomes a key into one or more databases. Unlike CNAM, it wouldn't = be hard to have several, including ones operated by major carriers and thir= d-party certifiers (e.g., a regulatory agency, such as a financial regulato= r, or professional licensing entity). Besides a query protocol that end sys= tems can execute, you don't need much. Primarily, the local bar association= needs to be able to ascertain that Attorney-at-Law Smith is entitled to us= e the phone number he claims in his profile.=0A= =0A= For the by-value model, I see this as a useful generalization of the IKE an= d 4474bis concepts, namely that a call request can have multiple =0A= =0A= (objects signed, signature, binding)=0A= =0A= headers. Thus, you could have=0A= =0A= (calling number, signature using STIR key, Date/To/...)=0A= =0A= as well as=0A= =0A= (display name, signature using PK of verizon.com, Date/To/...)=0A= =0A= This allows for the case that the carrier or a third party validates the ca= lling entity business name. This simply says "this is the name inserted by = the carrier, not the caller or some third party". Whether that is sufficien= t to be useful depends on the policy of the signer. This requires that the = callee can verify that verizon.com is indeed the carrier of record for this= number.=0A= =0A= I don't think it's as useful to have the entity assigned the number use its= STIR key to sign, as that simply indicates that nobody else has messed wit= h the display information.=0A= =0A= I don't expect users to evaluate this - much of the filtering and scoring w= ill be done by third parties on behalf of the callee. If pinkcarrier.com si= gns any garbage, this will land them on the do-not-trust list fairly quickl= y and reputable businesses that prefer to not be tarred by that behavior ma= y decide to go elsewhere.=0A= =0A= We also seem to have no difficulty dealing with gray in spam filtering, as = in the scores that SpamAssassin attaches to messages.=0A= =0A= I don't see disagreement that verifiable names are not foolproof or can pre= vent all fraudulent activity. I'm happy if it raises the bar or roughly res= tores the level of trust that existed in the pre-VoIP days.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Dwight, Ti= mothy M (Tim) [timothy.dwight@verizon.com]=0A= Sent: Friday, August 23, 2013 3:38 PM=0A= To: Hadriel Kaplan; Brian Rosen=0A= Cc: stir@ietf.org=0A= Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework)=0A= =0A= Henning previously suggested what I understood to be a "database of names" = into which entities concerned that their name might be spoofed, could regis= ter themselves. Banks for example. The idea was that to validate a "calli= ng name" you could look up that name in this database, and get in return a = list of phone numbers they've registered as numbers they use to call people= . You could then check to see if the [validated] calling number was on tha= t list.=0A= =0A= That seems to me to have at least one hole, though. Duplicate names. You = can't disallow them because in the real world it happens. But maybe in the= process of registering your name, you get a unique identifier. And that i= dentifier gets signaled in some new parameter, in addition to the textual n= ame. The validation function could then look up this identifier to determi= ne (a) what name should be displayed, and (b) whether the [validated] calli= ng number is registered as associated with that name.=0A= =0A= Brian is correct that I suggested the validation function might be on the o= riginating side of the call; which would require some way to carry the resu= lt and the entity claiming to have produced that result, in the signaling m= essage.=0A= =0A= That doesn't of course prevent the terminating network validating it again,= if the entity claiming to have performed that validation, isn't deemed tru= stworthy.=0A= =0A= I'm happy to take the topic of how best to authenticate calling name, to an= other list. But if the initial STIR work specifies signaling enhancements,= I would like to see them include a way to convey the result of a calling n= ame validation performed somewhere upstream. Nothing about how to do the v= alidation [yet]. Let the folks who elect to post to this other list, work = on that. Just a container for the result.=0A= =0A= tim=0A= =0A= -----Original Message-----=0A= From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan=0A= Sent: Friday, August 23, 2013 1:44 PM=0A= To: Brian Rosen=0A= Cc: stir@ietf.org=0A= Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework)=0A= =0A= =0A= On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote:=0A= =0A= > The idea is that you get a 3rd party to provide the level of assurance, h= oping that the number of such services would be small and thus the trustwor= hlyness of them being understood widely. The termination end can decide if= it trusts that third party, and, if necessary, use an alternative service = if it doesn't.=0A= =0A= We have that already today: just in the USA there are over a dozen LIDB pro= viders, and even more CNAM DB providers. The validity of the data in them = varies, but they're essentially the "3rd party" model.=0A= =0A= =0A= > The reason to keep discussing this in stir is to emphasize that the mecha= nism may need to carry some other data, like the assurance on the name, in = addition to what we're already discussing.=0A= =0A= That's a good point.=0A= =0A= One of the things we talked about originally was that a valid calling numbe= r was a precursor to calling name, because the name lookup is based on the = calling number for the key. So I think for the current LIDB/CNAM models th= e currently-proposed STIR in-band data is sufficient (or at least I was thi= nking that way when I wrote the draft-IKES mechanism).=0A= =0A= Regardless, my concern is I can easily foresee a calling name discussion kn= ocking us off-the-tracks very quickly. For example I expect the feature-cr= eep to begin with including various other forms of name identifiers, such a= s email or social-site-based names, and then getting into the need for an I= dP model, SSO/SAML/OpenID, OAuth, etc. Or we start debating how to disting= uish legitimate financial banks from blood banks and sperm banks; or how us= ers receiving just the string "Fidelity" disambiguate when they get calls f= rom: Fidelity Investments, Fidelity National Financial, Fidelity National I= nformation Services, USS Fidelity, Fidelity Records, Fidelity IL, Fidelity = MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fidelity Township= NJ. (all legal, separate entities in the US)=0A= =0A= I don't really know how to prevent such ratholes, but maybe we need a separ= ate mailing list for the name discussions (i.e. for a research/design-team)= to separate that stuff out and keep this one focused on the charter's scop= e?=0A= =0A= -hadriel=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From Henning.Schulzrinne@fcc.gov Fri Aug 23 19:25:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D6721F9E73 for ; Fri, 23 Aug 2013 19:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+D0CN3IcS6r for ; Fri, 23 Aug 2013 19:25:41 -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 29C4B21F9E40 for ; Fri, 23 Aug 2013 19:25:40 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" , Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: AQHOoDDYSlcmU703FUC8K86PUli1V5mjc0aAgAAjGbSAAAq1/A== Date: Sat, 24 Aug 2013 02:25:35 +0000 References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> , <2B0F677F0B95454297753F58D4A07FA3012AF557CB@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 02:25:45 -0000 To make this a bit more concrete, a few years ago Kumiko Ono and I worked o= n a related system that does a bit more.=0A= =0A= See=0A= =0A= http://www.cs.columbia.edu/~kumiko/IETF_doc/draft-ono-dispatch-attribute-va= lidation-00.html=0A= =0A= We didn't have validated numbers to rely on, so the trade-offs likely will = lead to a different solution with STIR.=0A= =0A= Henning= From hadriel.kaplan@oracle.com Fri Aug 23 21:12:55 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F007A21F8C3E for ; Fri, 23 Aug 2013 21:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3blZCreFoKg for ; Fri, 23 Aug 2013 21:12:51 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4D62021F8B35 for ; Fri, 23 Aug 2013 21:12:51 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7O4Cn4K027061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Aug 2013 04:12:49 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7O4CmGc002902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Aug 2013 04:12:48 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7O4Cl3Y028791; Sat, 24 Aug 2013 04:12:47 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Aug 2013 21:12:47 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Sat, 24 Aug 2013 00:12:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> , <2B0F677F0B95454297753F58D4A07FA3012AF557CB@FHDP1LUMXC7V31.us.one.verizon.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org WG" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 04:12:56 -0000 I've thought about that first by-reference model before as well, but I'm = pretty sure nothing needs to change in IKES/4474bis to achieve it = someday. Not 100% sure, but pretty sure. For the second one, I'm also pretty sure nothing needs to change in = IKES/4474bis, since you're talking about it as using a separate = header/key/signature/etc. Right? I actually think there are additional, completely different, ways to = achieve this. But we can take that discussion off to a new list. :) For the shades-of-gray scoring complexity, I don't think email is very = analogous, in the sense that email has a lot of information to make spam = determination with. Phone call requests... not so much; and = human/business name strings even less so. Realistically it would boil = down to whether you trust the signing carrier/identity-service or not, = kinda similar to the old email DNSBLs. [Btw, there were lawsuits over = DNSBLs, but the lawsuits were eventually defeated] -hadriel On Aug 23, 2013, at 10:12 PM, Henning Schulzrinne = wrote: > Just to clarify, as my original description obviously was lacking: >=20 > I see two models, the "by-value" (display name or similar call-info = information) version, along the lines that Brian has been describing, = and the "by-reference" lookup model. >=20 > For the latter, my rough notion is similar to whois - the (validated) = phone number becomes a key into one or more databases. Unlike CNAM, it = wouldn't be hard to have several, including ones operated by major = carriers and third-party certifiers (e.g., a regulatory agency, such as = a financial regulator, or professional licensing entity). Besides a = query protocol that end systems can execute, you don't need much. = Primarily, the local bar association needs to be able to ascertain that = Attorney-at-Law Smith is entitled to use the phone number he claims in = his profile. >=20 > For the by-value model, I see this as a useful generalization of the = IKE and 4474bis concepts, namely that a call request can have multiple=20= >=20 > (objects signed, signature, binding) >=20 > headers. Thus, you could have >=20 > (calling number, signature using STIR key, Date/To/...) >=20 > as well as >=20 > (display name, signature using PK of verizon.com, Date/To/...) >=20 > This allows for the case that the carrier or a third party validates = the calling entity business name. This simply says "this is the name = inserted by the carrier, not the caller or some third party". Whether = that is sufficient to be useful depends on the policy of the signer. = This requires that the callee can verify that verizon.com is indeed the = carrier of record for this number. >=20 > I don't think it's as useful to have the entity assigned the number = use its STIR key to sign, as that simply indicates that nobody else has = messed with the display information. >=20 > I don't expect users to evaluate this - much of the filtering and = scoring will be done by third parties on behalf of the callee. If = pinkcarrier.com signs any garbage, this will land them on the = do-not-trust list fairly quickly and reputable businesses that prefer to = not be tarred by that behavior may decide to go elsewhere. >=20 > We also seem to have no difficulty dealing with gray in spam = filtering, as in the scores that SpamAssassin attaches to messages. >=20 > I don't see disagreement that verifiable names are not foolproof or = can prevent all fraudulent activity. I'm happy if it raises the bar or = roughly restores the level of trust that existed in the pre-VoIP days. >=20 > Henning >=20 > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of = Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] > Sent: Friday, August 23, 2013 3:38 PM > To: Hadriel Kaplan; Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to = Charter, Early Homework) >=20 > Henning previously suggested what I understood to be a "database of = names" into which entities concerned that their name might be spoofed, = could register themselves. Banks for example. The idea was that to = validate a "calling name" you could look up that name in this database, = and get in return a list of phone numbers they've registered as numbers = they use to call people. You could then check to see if the [validated] = calling number was on that list. >=20 > That seems to me to have at least one hole, though. Duplicate names. = You can't disallow them because in the real world it happens. But maybe = in the process of registering your name, you get a unique identifier. = And that identifier gets signaled in some new parameter, in addition to = the textual name. The validation function could then look up this = identifier to determine (a) what name should be displayed, and (b) = whether the [validated] calling number is registered as associated with = that name. >=20 > Brian is correct that I suggested the validation function might be on = the originating side of the call; which would require some way to carry = the result and the entity claiming to have produced that result, in the = signaling message. >=20 > That doesn't of course prevent the terminating network validating it = again, if the entity claiming to have performed that validation, isn't = deemed trustworthy. >=20 > I'm happy to take the topic of how best to authenticate calling name, = to another list. But if the initial STIR work specifies signaling = enhancements, I would like to see them include a way to convey the = result of a calling name validation performed somewhere upstream. = Nothing about how to do the validation [yet]. Let the folks who elect = to post to this other list, work on that. Just a container for the = result. >=20 > tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Hadriel Kaplan > Sent: Friday, August 23, 2013 1:44 PM > To: Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to = Charter, Early Homework) >=20 >=20 > On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote: >=20 >> The idea is that you get a 3rd party to provide the level of = assurance, hoping that the number of such services would be small and = thus the trustworhlyness of them being understood widely. The = termination end can decide if it trusts that third party, and, if = necessary, use an alternative service if it doesn't. >=20 > We have that already today: just in the USA there are over a dozen = LIDB providers, and even more CNAM DB providers. The validity of the = data in them varies, but they're essentially the "3rd party" model. >=20 >=20 >> The reason to keep discussing this in stir is to emphasize that the = mechanism may need to carry some other data, like the assurance on the = name, in addition to what we're already discussing. >=20 > That's a good point. >=20 > One of the things we talked about originally was that a valid calling = number was a precursor to calling name, because the name lookup is based = on the calling number for the key. So I think for the current LIDB/CNAM = models the currently-proposed STIR in-band data is sufficient (or at = least I was thinking that way when I wrote the draft-IKES mechanism). >=20 > Regardless, my concern is I can easily foresee a calling name = discussion knocking us off-the-tracks very quickly. For example I = expect the feature-creep to begin with including various other forms of = name identifiers, such as email or social-site-based names, and then = getting into the need for an IdP model, SSO/SAML/OpenID, OAuth, etc. Or = we start debating how to distinguish legitimate financial banks from = blood banks and sperm banks; or how users receiving just the string = "Fidelity" disambiguate when they get calls from: Fidelity Investments, = Fidelity National Financial, Fidelity National Information Services, USS = Fidelity, Fidelity Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, = Fidelity Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all legal, = separate entities in the US) >=20 > I don't really know how to prevent such ratholes, but maybe we need a = separate mailing list for the name discussions (i.e. for a = research/design-team) to separate that stuff out and keep this one = focused on the charter's scope? >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Mon Aug 26 07:48:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1862A11E81B2 for ; Mon, 26 Aug 2013 07:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRwdUO6tKFP4 for ; Mon, 26 Aug 2013 07:48: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 8F26B11E81AC for ; Mon, 26 Aug 2013 07:48:12 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' Thread-Topic: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) Thread-Index: AQHOoIAz4OlUEkUxSUqMJe+CYN6XnJmnk26Q Date: Mon, 26 Aug 2013 14:48:11 +0000 References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> , <2B0F677F0B95454297753F58D4A07FA3012AF557CB@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org WG" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 14:48:20 -0000 I agree as long as we have sufficient flexibility and clarity on exactly wh= at signing means (e.g., we may need to discuss string normalization rules, = in case SBCs un-fold display names or change white spaces in display names)= . For scoring, I suspect we need two different indicators, namely a descripti= on of how the originating carrier or other entity knows the name of the cal= ler and a confidence level. If you look at identity verification today, per= formed by companies such as Experian, they provide such 0-100 scores. This = is purely based on identity, not on any content. The similarity is simply t= hat filtering entities have figured out ways to set thresholds on those num= bers, based on experience and risk/nuisance tolerance. For the indicator, I'm picturing indications such as "no verification" (thi= s would be for cash prepay), "consumer billing relationship" (where the cre= dit card name agrees with the display name) to "commercial billing relation= ship" (where the carrier is dealing with a known entity that it extends cre= dit to and presumably has validated using typical commercial credit checks)= . -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Saturday, August 24, 2013 12:13 AM To: Henning Schulzrinne Cc: stir@ietf.org WG Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework) I've thought about that first by-reference model before as well, but I'm pr= etty sure nothing needs to change in IKES/4474bis to achieve it someday. N= ot 100% sure, but pretty sure. For the second one, I'm also pretty sure nothing needs to change in IKES/44= 74bis, since you're talking about it as using a separate header/key/signatu= re/etc. Right? I actually think there are additional, completely different, ways to achiev= e this. But we can take that discussion off to a new list. :) For the shades-of-gray scoring complexity, I don't think email is very anal= ogous, in the sense that email has a lot of information to make spam determ= ination with. Phone call requests... not so much; and human/business name = strings even less so. Realistically it would boil down to whether you trus= t the signing carrier/identity-service or not, kinda similar to the old ema= il DNSBLs. [Btw, there were lawsuits over DNSBLs, but the lawsuits were ev= entually defeated] -hadriel From br@brianrosen.net Mon Aug 26 08:56:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF36621E8091 for ; Mon, 26 Aug 2013 08:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh-d7SucbdoX for ; Mon, 26 Aug 2013 08:56:27 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0513221E8088 for ; Mon, 26 Aug 2013 08:56:26 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so3551356pbc.7 for ; Mon, 26 Aug 2013 08:56:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yyUmY7rGiGNJn7zH6He/JUURDS4Zvc2wMrEwEw/HNE4=; b=YvDtE63kciOw7Apge+ZPHwKDXmdPwDMgiBtBecrGuL5eNE+3gMyEIeLtfnPpCH61Ei +6xqfFA0/QqareJnYyeH3fkZIS6vHW4+pPk8xFMaQDk7GnsL0WFPly1QMqVpnZNutXn/ 9QVEcmSDEHrG+95uqSdDgpiGhp/jmz1OAWYs1WrDIwp8iWtVztJEC+iN17P+qlPvyZgb Igj90dx0bpjpHRsNFsOUbC3pvVi7I+WeBzRkDA/9LQoonuYVMedpQgSyId2vR0t38RZr cqUTe7GWnqtMd8Q1eWfFU9QJpU8y/evBWhes+IPL8RMYrExHVXryhg6CYNFrIW6vIypr hiQQ== X-Gm-Message-State: ALoCoQmQO7HPZlkGwLTaEtRWvIxRXFLcyJFpdB9t/Vhw73nePA3ziNiMgry9WB0QZ2OAndxk19ED MIME-Version: 1.0 X-Received: by 10.66.118.129 with SMTP id km1mr9064215pab.127.1377532586674; Mon, 26 Aug 2013 08:56:26 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Mon, 26 Aug 2013 08:56:26 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012AF557CB@FHDP1LUMXC7V31.us.one.verizon.com> Date: Mon, 26 Aug 2013 11:56:26 -0400 Message-ID: From: Brian Rosen To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=e89a8ffbab6b7ee47e04e4dbcc0c Cc: "stir@ietf.org WG" , Hadriel Kaplan Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 15:56:32 -0000 --e89a8ffbab6b7ee47e04e4dbcc0c Content-Type: text/plain; charset=ISO-8859-1 We have three players: 1. The origination device or service provider 2. The validation service 3. The termination device or service provider The origination asserts a name The validation service validates it and creates a score. It protects it in some way that makes the package (name and score) not modifiable and where the identity of the validation service is preserved The origination carries the package in the signaling I believe that keeping the name separate from the number won't work. The same entity that asserts the number asserts the name. So, I think that the package is covered by the signature of the entity that asserts the name and the number. One way to do this is to have the score a parameter in the header we're discussing for number, as well as a signature of the score, name and number created by the validator. What is needed is a way to extend the header to add parameters that are covered by the signature of the number holder. We could then use that to add the score and validator signature for the name. Brian On Mon, Aug 26, 2013 at 10:48 AM, Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> wrote: > I agree as long as we have sufficient flexibility and clarity on exactly > what signing means (e.g., we may need to discuss string normalization > rules, in case SBCs un-fold display names or change white spaces in display > names). > > For scoring, I suspect we need two different indicators, namely a > description of how the originating carrier or other entity knows the name > of the caller and a confidence level. If you look at identity verification > today, performed by companies such as Experian, they provide such 0-100 > scores. This is purely based on identity, not on any content. The > similarity is simply that filtering entities have figured out ways to set > thresholds on those numbers, based on experience and risk/nuisance > tolerance. > > For the indicator, I'm picturing indications such as "no verification" > (this would be for cash prepay), "consumer billing relationship" (where the > credit card name agrees with the display name) to "commercial billing > relationship" (where the carrier is dealing with a known entity that it > extends credit to and presumably has validated using typical commercial > credit checks). > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Saturday, August 24, 2013 12:13 AM > To: Henning Schulzrinne > Cc: stir@ietf.org WG > Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, > Early Homework) > > > I've thought about that first by-reference model before as well, but I'm > pretty sure nothing needs to change in IKES/4474bis to achieve it someday. > Not 100% sure, but pretty sure. > > For the second one, I'm also pretty sure nothing needs to change in > IKES/4474bis, since you're talking about it as using a separate > header/key/signature/etc. Right? > > I actually think there are additional, completely different, ways to > achieve this. But we can take that discussion off to a new list. :) > > For the shades-of-gray scoring complexity, I don't think email is very > analogous, in the sense that email has a lot of information to make spam > determination with. Phone call requests... not so much; and human/business > name strings even less so. Realistically it would boil down to whether you > trust the signing carrier/identity-service or not, kinda similar to the old > email DNSBLs. [Btw, there were lawsuits over DNSBLs, but the lawsuits were > eventually defeated] > > -hadriel > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --e89a8ffbab6b7ee47e04e4dbcc0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We have three players:
1. The origination device or se= rvice provider
2. The validation service
3. The termina= tion device or service provider

The origination as= serts a name
The validation service validates it and creates a score. =A0It protect= s it in some way that makes the package (name and score) not modifiable and= where the identity of the validation service is preserved
The or= igination carries the package in the signaling=A0

I believe that keeping the name separate from the numbe= r won't work. =A0The same entity that asserts the number asserts the na= me. =A0So, I think that the package is covered by the signature of the enti= ty that asserts the name and the number. =A0One way to do this is to have t= he score a parameter in the header we're discussing for number, as well= as a signature of the score, name and number created by the validator. =A0=

What is needed is a way to extend the header to add par= ameters that are covered by the signature of the number holder.
W= e could then use that to add the score and validator signature for the name= .

Brian


On Mon, Aug 26, 2013 at 10:48 AM, Henning Schulzrin= ne <Henning.Schulzrinne@fcc.gov> wrote:
I agree as long as we have sufficient flexib= ility and clarity on exactly what signing means (e.g., we may need to discu= ss string normalization rules, in case SBCs un-fold display names or change= white spaces in display names).

For scoring, I suspect we need two different indicators, namely a descripti= on of how the originating carrier or other entity knows the name of the cal= ler and a confidence level. If you look at identity verification today, per= formed by companies such as Experian, they provide such 0-100 scores. This = is purely based on identity, not on any content. The similarity is simply t= hat filtering entities have figured out ways to set thresholds on those num= bers, based on experience and risk/nuisance tolerance.

For the indicator, I'm picturing indications such as "no verificat= ion" (this would be for cash prepay), "consumer billing relations= hip" (where the credit card name agrees with the display name) to &quo= t;commercial billing relationship" (where the carrier is dealing with = a known entity that it extends credit to and presumably has validated using= typical commercial credit checks).

-----Original Message-----
From: Hadriel Kaplan [mailto:h= adriel.kaplan@oracle.com]
Sent: Saturday, August 24, 2013 12:13 AM
To: Henning Schulzrinne
Cc: stir@ietf.org WG
Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework)


I've thought about that first by-referen= ce model before as well, but I'm pretty sure nothing needs to change in= IKES/4474bis to achieve it someday. =A0Not 100% sure, but pretty sure.

For the second one, I'm also pretty sure nothing needs to change in IKE= S/4474bis, since you're talking about it as using a separate header/key= /signature/etc. =A0Right?

I actually think there are additional, completely different, ways to achiev= e this. =A0But we can take that discussion off to a new list. :)

For the shades-of-gray scoring complexity, I don't think email is very = analogous, in the sense that email has a lot of information to make spam de= termination with. =A0Phone call requests... not so much; and human/business= name strings even less so. =A0Realistically it would boil down to whether = you trust the signing carrier/identity-service or not, kinda similar to the= old email DNSBLs. =A0[Btw, there were lawsuits over DNSBLs, but the lawsui= ts were eventually defeated]

-hadriel


_____________________________= __________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--e89a8ffbab6b7ee47e04e4dbcc0c-- From alex@bobotek.net Mon Aug 26 11:34:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FD111E81E6 for ; Mon, 26 Aug 2013 11:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFG6uWQ4iScU for ; Mon, 26 Aug 2013 11:34:36 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id DB76821F9EB8 for ; Mon, 26 Aug 2013 11:34:35 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta15.emeryville.ca.mail.comcast.net with comcast id HSot1m0041smiN4AFWaboT; Mon, 26 Aug 2013 18:34:35 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta20.emeryville.ca.mail.comcast.net with comcast id HWaZ1m00R4EJ4tY8gWaaTn; Mon, 26 Aug 2013 18:34:35 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Mon, 26 Aug 2013 11:26:48 -0700 From: Alex Bobotek To: Henning Schulzrinne , "Dwight, Timothy M (Tim)" , Hadriel Kaplan , Brian Rosen Date: Mon, 26 Aug 2013 11:26:48 -0700 Thread-Topic: [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzA== Message-ID: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377542075; bh=YdDu33hPeVwc8YZp05S7Kw3lHEy/VcvgVgpMjlmTrPs=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=CmUnFwQH+Ns6zX/9sF0mf2ibo0xPn9JRiOVymaIsAIZeWt80008QxGiLpYF+De1TY hZRoYDFOmJO+RS9p34WfQMWTq5xnWqaDbKU+7e/F23PiaMlXl7bw5JsQZO4q4VRRoq DJT8yNsMxHfJ1Q+xc1htAXP/7dGaDACP16Gtr5NPcfkY+pTtMBcQuNuQFsBMaQ6sLM yDbO/Emke5L3rfsslD/+p39ap4aU7DmTZfp6ZzZC5ibuf8giRe2EWO+Q4S7uZW3AUP 2pyRDCyIgOUdJZUoZy9pE6RcjGoXklTRS9mt8+eNuoZaW4f4dg5q+upa3oiqZNO7rf w53pzAq23hl9A== Cc: "stir@ietf.org" Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 18:34:41 -0000 Tim's point about duplicate names and Hadrial's about similar names are imp= ortant in anti-phishing and anti-spoofing contexts. Identity (e.g., phone = #), display name and reputation are different concepts. The display name = associated with a number may have some bearing on its reputation; however, = display name (e.g., "Example Bank" vs. "Examp1e Bank", duplicates and simi= lar variations) is insufficient to permit humans to reliably discern reputa= tion. =20 I'm certainly not arguing against display names being certified by one or m= ore parties, or there being reputable number<-->name mapping databases. =20 I am arguing _for_ the optional inclusion of reputation information in a la= rger framework. The end user can only to be protected from phishing and sp= oofing by the inclusion of reputation information. =20 This reputation should be associated with an _identity_ and may be based o= n=20 * authorities' certifications of reputation (not just name) * community-based reputation * other means The reputation-based models implemented in some browsers, commercial anti-v= irus solutions file reputation and DKIM/DMARC in email all bear some relev= ance and are worth studying. =20 IMHO, the model should allow for the inclusion of optional reputation infor= mation, allowing screening, and user agent display and reporting. Regards, Alex Bobotek alex@bobotek.net -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Friday, August 23, 2013 7:13 PM To: Dwight, Timothy M (Tim); Hadriel Kaplan; Brian Rosen Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework) Just to clarify, as my original description obviously was lacking: I see two models, the "by-value" (display name or similar call-info informa= tion) version, along the lines that Brian has been describing, and the "by-= reference" lookup model. For the latter, my rough notion is similar to whois - the (validated) phone= number becomes a key into one or more databases. Unlike CNAM, it wouldn't = be hard to have several, including ones operated by major carriers and thir= d-party certifiers (e.g., a regulatory agency, such as a financial regulato= r, or professional licensing entity). Besides a query protocol that end sys= tems can execute, you don't need much. Primarily, the local bar association= needs to be able to ascertain that Attorney-at-Law Smith is entitled to us= e the phone number he claims in his profile. For the by-value model, I see this as a useful generalization of the IKE an= d 4474bis concepts, namely that a call request can have multiple=20 (objects signed, signature, binding) headers. Thus, you could have (calling number, signature using STIR key, Date/To/...) as well as (display name, signature using PK of verizon.com, Date/To/...) This allows for the case that the carrier or a third party validates the ca= lling entity business name. This simply says "this is the name inserted by = the carrier, not the caller or some third party". Whether that is sufficien= t to be useful depends on the policy of the signer. This requires that the = callee can verify that verizon.com is indeed the carrier of record for this= number. I don't think it's as useful to have the entity assigned the number use its= STIR key to sign, as that simply indicates that nobody else has messed wit= h the display information. I don't expect users to evaluate this - much of the filtering and scoring w= ill be done by third parties on behalf of the callee. If pinkcarrier.com si= gns any garbage, this will land them on the do-not-trust list fairly quickl= y and reputable businesses that prefer to not be tarred by that behavior ma= y decide to go elsewhere. We also seem to have no difficulty dealing with gray in spam filtering, as = in the scores that SpamAssassin attaches to messages. I don't see disagreement that verifiable names are not foolproof or can pre= vent all fraudulent activity. I'm happy if it raises the bar or roughly res= tores the level of trust that existed in the pre-VoIP days. Henning ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Dwight, Ti= mothy M (Tim) [timothy.dwight@verizon.com] Sent: Friday, August 23, 2013 3:38 PM To: Hadriel Kaplan; Brian Rosen Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework) Henning previously suggested what I understood to be a "database of names" = into which entities concerned that their name might be spoofed, could regis= ter themselves. Banks for example. The idea was that to validate a "calli= ng name" you could look up that name in this database, and get in return a = list of phone numbers they've registered as numbers they use to call people= . You could then check to see if the [validated] calling number was on tha= t list. That seems to me to have at least one hole, though. Duplicate names. You = can't disallow them because in the real world it happens. But maybe in the= process of registering your name, you get a unique identifier. And that i= dentifier gets signaled in some new parameter, in addition to the textual n= ame. The validation function could then look up this identifier to determi= ne (a) what name should be displayed, and (b) whether the [validated] calli= ng number is registered as associated with that name. Brian is correct that I suggested the validation function might be on the o= riginating side of the call; which would require some way to carry the resu= lt and the entity claiming to have produced that result, in the signaling m= essage. That doesn't of course prevent the terminating network validating it again,= if the entity claiming to have performed that validation, isn't deemed tru= stworthy. I'm happy to take the topic of how best to authenticate calling name, to an= other list. But if the initial STIR work specifies signaling enhancements,= I would like to see them include a way to convey the result of a calling n= ame validation performed somewhere upstream. Nothing about how to do the v= alidation [yet]. Let the folks who elect to post to this other list, work = on that. Just a container for the result. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Friday, August 23, 2013 1:44 PM To: Brian Rosen Cc: stir@ietf.org Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework) On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote: > The idea is that you get a 3rd party to provide the level of assurance, h= oping that the number of such services would be small and thus the trustwor= hlyness of them being understood widely. The termination end can decide if= it trusts that third party, and, if necessary, use an alternative service = if it doesn't. We have that already today: just in the USA there are over a dozen LIDB pro= viders, and even more CNAM DB providers. The validity of the data in them = varies, but they're essentially the "3rd party" model. > The reason to keep discussing this in stir is to emphasize that the mecha= nism may need to carry some other data, like the assurance on the name, in = addition to what we're already discussing. That's a good point. One of the things we talked about originally was that a valid calling numbe= r was a precursor to calling name, because the name lookup is based on the = calling number for the key. So I think for the current LIDB/CNAM models th= e currently-proposed STIR in-band data is sufficient (or at least I was thi= nking that way when I wrote the draft-IKES mechanism). Regardless, my concern is I can easily foresee a calling name discussion kn= ocking us off-the-tracks very quickly. For example I expect the feature-cr= eep to begin with including various other forms of name identifiers, such a= s email or social-site-based names, and then getting into the need for an I= dP model, SSO/SAML/OpenID, OAuth, etc. Or we start debating how to disting= uish legitimate financial banks from blood banks and sperm banks; or how us= ers receiving just the string "Fidelity" disambiguate when they get calls f= rom: Fidelity Investments, Fidelity National Financial, Fidelity National I= nformation Services, USS Fidelity, Fidelity Records, Fidelity IL, Fidelity = MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fidelity Township= NJ. (all legal, separate entities in the US) I don't really know how to prevent such ratholes, but maybe we need a separ= ate mailing list for the name discussions (i.e. for a research/design-team)= to separate that stuff out and keep this one focused on the charter's scop= e? -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From stephen.farrell@cs.tcd.ie Mon Aug 26 14:14:38 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45A721F9DB8 for ; Mon, 26 Aug 2013 14:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.598 X-Spam-Level: X-Spam-Status: No, score=-100.598 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt3M+i5bFTQu for ; Mon, 26 Aug 2013 14:14:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4C89021F9E5C for ; Mon, 26 Aug 2013 14:14:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B54F8BE5D; Mon, 26 Aug 2013 22:14:32 +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 6Keg6hsr3igg; Mon, 26 Aug 2013 22:14:27 +0100 (IST) Received: from [192.168.1.5] (nova001-254.cust.nova.is [78.40.254.1]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 533A3BE54; Mon, 26 Aug 2013 22:14:27 +0100 (IST) References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> Mime-Version: 1.0 (1.0) In-Reply-To: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Stephen Farrell Date: Mon, 26 Aug 2013 21:14:23 +0000 To: Alex Bobotek Cc: "stir@ietf.org" , Brian Rosen , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 21:14:38 -0000 I'm very confused by this whole thread. Do the folks advocating this extensi= on of scope want to rerun the stir BoF in Vancouver? If not, please say how t= his fits the current draft charter. The reason for my concern btw is less process than a serious worry that stir= will fail if this is anywhere near the initial scope. S On 26 Aug 2013, at 18:26, Alex Bobotek wrote: > Tim's point about duplicate names and Hadrial's about similar names are im= portant in anti-phishing and anti-spoofing contexts. Identity (e.g., phone #= ), display name and reputation are different concepts. The display name as= sociated with a number may have some bearing on its reputation; however, dis= play name (e.g., "Example Bank" vs. "Examp1e Bank", duplicates and similar v= ariations) is insufficient to permit humans to reliably discern reputation. = =20 >=20 > I'm certainly not arguing against display names being certified by one or m= ore parties, or there being reputable number<-->name mapping databases. =20 > I am arguing _for_ the optional inclusion of reputation information in a l= arger framework. The end user can only to be protected from phishing and sp= oofing by the inclusion of reputation information. =20 >=20 > This reputation should be associated with an _identity_ and may be based o= n=20 > * authorities' certifications of reputation (not just name) > * community-based reputation > * other means >=20 > The reputation-based models implemented in some browsers, commercial anti-= virus solutions file reputation and DKIM/DMARC in email all bear some relev= ance and are worth studying. =20 >=20 > IMHO, the model should allow for the inclusion of optional reputation info= rmation, allowing screening, and user agent display and reporting. >=20 > Regards, >=20 > Alex Bobotek > alex@bobotek.net >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of He= nning Schulzrinne > Sent: Friday, August 23, 2013 7:13 PM > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,= Early Homework) >=20 > Just to clarify, as my original description obviously was lacking: >=20 > I see two models, the "by-value" (display name or similar call-info inform= ation) version, along the lines that Brian has been describing, and the "by-= reference" lookup model. >=20 > For the latter, my rough notion is similar to whois - the (validated) phon= e number becomes a key into one or more databases. Unlike CNAM, it wouldn't b= e hard to have several, including ones operated by major carriers and third-= party certifiers (e.g., a regulatory agency, such as a financial regulator, o= r professional licensing entity). Besides a query protocol that end systems c= an execute, you don't need much. Primarily, the local bar association needs t= o be able to ascertain that Attorney-at-Law Smith is entitled to use the pho= ne number he claims in his profile. >=20 > For the by-value model, I see this as a useful generalization of the IKE a= nd 4474bis concepts, namely that a call request can have multiple=20 >=20 > (objects signed, signature, binding) >=20 > headers. Thus, you could have >=20 > (calling number, signature using STIR key, Date/To/...) >=20 > as well as >=20 > (display name, signature using PK of verizon.com, Date/To/...) >=20 > This allows for the case that the carrier or a third party validates the c= alling entity business name. This simply says "this is the name inserted by t= he carrier, not the caller or some third party". Whether that is sufficient t= o be useful depends on the policy of the signer. This requires that the call= ee can verify that verizon.com is indeed the carrier of record for this numb= er. >=20 > I don't think it's as useful to have the entity assigned the number use it= s STIR key to sign, as that simply indicates that nobody else has messed wit= h the display information. >=20 > I don't expect users to evaluate this - much of the filtering and scoring w= ill be done by third parties on behalf of the callee. If pinkcarrier.com sig= ns any garbage, this will land them on the do-not-trust list fairly quickly a= nd reputable businesses that prefer to not be tarred by that behavior may de= cide to go elsewhere. >=20 > We also seem to have no difficulty dealing with gray in spam filtering, as= in the scores that SpamAssassin attaches to messages. >=20 > I don't see disagreement that verifiable names are not foolproof or can pr= event all fraudulent activity. I'm happy if it raises the bar or roughly res= tores the level of trust that existed in the pre-VoIP days. >=20 > Henning >=20 > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Dwight, T= imothy M (Tim) [timothy.dwight@verizon.com] > Sent: Friday, August 23, 2013 3:38 PM > To: Hadriel Kaplan; Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,= Early Homework) >=20 > Henning previously suggested what I understood to be a "database of names"= into which entities concerned that their name might be spoofed, could regis= ter themselves. Banks for example. The idea was that to validate a "callin= g name" you could look up that name in this database, and get in return a li= st of phone numbers they've registered as numbers they use to call people. Y= ou could then check to see if the [validated] calling number was on that lis= t. >=20 > That seems to me to have at least one hole, though. Duplicate names. You= can't disallow them because in the real world it happens. But maybe in the= process of registering your name, you get a unique identifier. And that id= entifier gets signaled in some new parameter, in addition to the textual nam= e. The validation function could then look up this identifier to determine (= a) what name should be displayed, and (b) whether the [validated] calling nu= mber is registered as associated with that name. >=20 > Brian is correct that I suggested the validation function might be on the o= riginating side of the call; which would require some way to carry the resul= t and the entity claiming to have produced that result, in the signaling mes= sage. >=20 > That doesn't of course prevent the terminating network validating it again= , if the entity claiming to have performed that validation, isn't deemed tru= stworthy. >=20 > I'm happy to take the topic of how best to authenticate calling name, to a= nother list. But if the initial STIR work specifies signaling enhancements,= I would like to see them include a way to convey the result of a calling na= me validation performed somewhere upstream. Nothing about how to do the val= idation [yet]. Let the folks who elect to post to this other list, work on t= hat. Just a container for the result. >=20 > tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ha= driel Kaplan > Sent: Friday, August 23, 2013 1:44 PM > To: Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter,= Early Homework) >=20 >=20 > On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote: >=20 >> The idea is that you get a 3rd party to provide the level of assurance, h= oping that the number of such services would be small and thus the trustworh= lyness of them being understood widely. The termination end can decide if i= t trusts that third party, and, if necessary, use an alternative service if i= t doesn't. >=20 > We have that already today: just in the USA there are over a dozen LIDB pr= oviders, and even more CNAM DB providers. The validity of the data in them v= aries, but they're essentially the "3rd party" model. >=20 >=20 >> The reason to keep discussing this in stir is to emphasize that the mecha= nism may need to carry some other data, like the assurance on the name, in a= ddition to what we're already discussing. >=20 > That's a good point. >=20 > One of the things we talked about originally was that a valid calling numb= er was a precursor to calling name, because the name lookup is based on the c= alling number for the key. So I think for the current LIDB/CNAM models the c= urrently-proposed STIR in-band data is sufficient (or at least I was thinkin= g that way when I wrote the draft-IKES mechanism). >=20 > Regardless, my concern is I can easily foresee a calling name discussion k= nocking us off-the-tracks very quickly. For example I expect the feature-cr= eep to begin with including various other forms of name identifiers, such as= email or social-site-based names, and then getting into the need for an IdP= model, SSO/SAML/OpenID, OAuth, etc. Or we start debating how to distinguis= h legitimate financial banks from blood banks and sperm banks; or how users r= eceiving just the string "Fidelity" disambiguate when they get calls from: Fi= delity Investments, Fidelity National Financial, Fidelity National Informati= on Services, USS Fidelity, Fidelity Records, Fidelity IL, Fidelity MS, Fidel= ity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fidelity Township NJ. (all l= egal, separate entities in the US) >=20 > I don't really know how to prevent such ratholes, but maybe we need a sepa= rate mailing list for the name discussions (i.e. for a research/design-team)= to separate that stuff out and keep this one focused on the charter's scope= ? >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Aug 26 17:37:16 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7A611E825A for ; Mon, 26 Aug 2013 17:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5oy-jE0cpZo for ; Mon, 26 Aug 2013 17:37:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E37011E8242 for ; Mon, 26 Aug 2013 17:37:03 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7R0alU0006998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 00:36:47 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7R0ajK5011450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 00:36:46 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7R0ajCO011442; Tue, 27 Aug 2013 00:36:45 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Aug 2013 17:36:45 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 26 Aug 2013 20:36:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4C7565E5-8BD5-4733-8A6B-B3E81E457B84@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC2A473@EX2K10MB1.corp.yaanatech.com> <012801ce9cff$491305a0$db3910e0$@shockey.us> <8BB3A79D-8AFF-44D4-AD43-D4B8D47D4437@employees.org> <3DAAB15C-3EB0-4AA2-BF79-53A72937CDB4@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012AF557CB@FHDP1LUMXC7V31.us.one.verizon.com> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org WG" , Henning Schulzrinne Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 00:37:16 -0000 [We REALLY need to take this discussion off this list - it's a horse of = a different color] On Aug 26, 2013, at 11:56 AM, Brian Rosen wrote: > We have three players: > 1. The origination device or service provider > 2. The validation service > 3. The termination device or service provider >=20 > The origination asserts a name > The validation service validates it and creates a score. It protects = it in some way that makes the package (name and score) not modifiable = and where the identity of the validation service is preserved You mean like a certificate signed by the validation service "CA"? :) > The origination carries the package in the signaling=20 That would be putting a certificate in the SIP message, which we've = already said is a bridge too far. If we're willing to do it for calling = name, then we should be willing to do it for calling number. > I believe that keeping the name separate from the number won't work. = The same entity that asserts the number asserts the name. =20 If the same entity that asserts the number asserts the name, and the = same verifier verifies them, then I don't think you need to carry the = validation service's signed certificate in the SIP message. Have the = originator upload the signed calling name "package" into the same STIR = database used for calling number public keys. The verifier retrieves it = on SIP receipt. You still don't need the SIP message's STIR signature = sign anything extra. > So, I think that the package is covered by the signature of the entity = that asserts the name and the number. One way to do this is to have the = score a parameter in the header we're discussing for number, as well as = a signature of the score, name and number created by the validator. =20 I don't see why we need to protect the name from modification. All the = verifier has to do is do a string match of the received calling name vs. = the one it finds a "package" for in the STIR database for the number. = We know the SIP message came from the number because of STIR, ergo we = know what possible name(s) it could assert due to the "package". If a malicious party tries to change the name, it fails. If a malicious = party tries to re-use the STIR signed stuff in a new message with a = different name, it fails. You're not preventing anything by signing the = name. =20 If there are multiple possible names for a given number, singing it = would prevent someone from being able to change it from one valid name = to another. And if the name was empty in the SIP message (like the = caller wanted to withhold the name), then a malicious party could fill = it in with the valid name of the caller. But we've already agreed that = we're not worried about MITM for STIR, so I don't know why we'd be = worried about this particular attack vector. > What is needed is a way to extend the header to add parameters that = are covered by the signature of the number holder. > We could then use that to add the score and validator signature for = the name. The only purpose/value to digitally signing something is to prove that = you generated the something. For example to prevent someone else from = changing the thing you signed without breaking your signature, and for = others to know your key signed it. [Of course they don't actually know = who "you" are, except by having something else (such as a cert) binding = your public key to an identity of some kind (such as a phone number)] -hadriel From hadriel.kaplan@oracle.com Mon Aug 26 17:40:36 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6092D11E8117 for ; Mon, 26 Aug 2013 17:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3yhwdb1qvJH for ; Mon, 26 Aug 2013 17:40:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D722311E810D for ; Mon, 26 Aug 2013 17:40:28 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7R0eKiN032189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 00:40:21 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7R0eHrC024130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 00:40:19 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7R0eH4D001749; Tue, 27 Aug 2013 00:40:17 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Aug 2013 17:40:16 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 26 Aug 2013 20:40:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8CEA303F-7A29-4608-BF12-65F4F95BA74E@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org WG" Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 00:40:37 -0000 On Aug 26, 2013, at 5:14 PM, Stephen Farrell = wrote: > I'm very confused by this whole thread. Do the folks advocating this = extension of scope want to rerun the stir BoF in Vancouver? I don't think anyone has proposed that. (I hope?) > If not, please say how this fits the current draft charter. It doesn't. Richard Barnes sent in a request today for a separate = mailing list for the calling name stuff. I don't know how long it takes = to get one created though. > The reason for my concern btw is less process than a serious worry = that stir will fail if this is anywhere near the initial scope. yup. -hadriel From richard@shockey.us Tue Aug 27 05:52:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110FC11E8319 for ; Tue, 27 Aug 2013 05:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlACoQ2AQWba for ; Tue, 27 Aug 2013 05:52:10 -0700 (PDT) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id E7FBC11E8322 for ; Tue, 27 Aug 2013 05:52:01 -0700 (PDT) Received: (qmail 13462 invoked by uid 0); 27 Aug 2013 12:51:38 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.mail.unifiedlayer.com with SMTP; 27 Aug 2013 12:51:38 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=4QfAkyRV79s3m5m0NHW8jYvKpp802sHTCW+I+i7wLCw=; b=XuEZScTGK6RqjKnUIC/9pgpu1m+PmzBeh+YqQ6ZqTxP5THoBJItZEe2z1hzm4ehW8r+9QJTlIzvwSai2NxZk3SE1abQRv8mJpDZvLvOTE9khi2F1GcMU0lbV4WUh/0Ks; Received: from [71.114.100.16] (port=49676 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VEIkE-0004Ny-8u; Tue, 27 Aug 2013 06:51:38 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Stephen Farrell'" References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <8CEA303F-7A29-4608-BF12-65F4F95BA74E@oracle.com> In-Reply-To: <8CEA303F-7A29-4608-BF12-65F4F95BA74E@oracle.com> Date: Tue, 27 Aug 2013 08:51:36 -0400 Message-ID: <005f01cea324$2b302a10$81907e30$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJ/6HSZ0i2rb7Nzmzk2y2FpgUofqQMdQL0NAuVNhxuYFmG4cA== X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 12:52:15 -0000 +1 however a "shaken" list for not charter issues would not be unreasonable. It is a interesting thread and holds promise for future implementations. It is August after all. The charter is not yet approved. Conversations often become long winded. Ok question ... pretend you wanted a good primer "PKI for Teleco Dummies" any suggestions? Where would you start? Any good comparisons of various PKI implementations in the field? Successes failures etc? -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, August 26, 2013 8:40 PM To: Stephen Farrell Cc: stir@ietf.org WG Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) On Aug 26, 2013, at 5:14 PM, Stephen Farrell wrote: > I'm very confused by this whole thread. Do the folks advocating this extension of scope want to rerun the stir BoF in Vancouver? I don't think anyone has proposed that. (I hope?) > If not, please say how this fits the current draft charter. It doesn't. Richard Barnes sent in a request today for a separate mailing list for the calling name stuff. I don't know how long it takes to get one created though. > The reason for my concern btw is less process than a serious worry that stir will fail if this is anywhere near the initial scope. yup. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Tue Aug 27 06:05:13 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1962911E8309 for ; Tue, 27 Aug 2013 06:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zDV+RFxxMjK for ; Tue, 27 Aug 2013 06:05:08 -0700 (PDT) Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 14CFA11E818E for ; Tue, 27 Aug 2013 06:05:08 -0700 (PDT) Received: (qmail 20881 invoked by uid 0); 27 Aug 2013 13:04:40 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.mail.unifiedlayer.com with SMTP; 27 Aug 2013 13:04:40 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=FdsycVyypwHyiMwhriTJWynbOhqSyMBt0Bpdpya2Zc8=; b=hhNWCOk1Ik3F2McTOcWDK0W4lMGwJXPLlCR7g4iLvU0g6j3ZxCdrIixOME1zjS0dyJN2Ntfq2BYIKqAwmIRUwRsZecHKzIzlB4/LlDKw54G9zzbTEUR3U1CLqlHNZtVd; Received: from [71.114.100.16] (port=49816 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VEIwq-00085u-4n; Tue, 27 Aug 2013 07:04:40 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Stephen Farrell'" References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <8CEA303F-7A29-4608-BF12-65F4F95BA74E@oracle.com> <005f01cea324$2b302a10$81907e30$@shockey.us> In-Reply-To: <005f01cea324$2b302a10$81907e30$@shockey.us> Date: Tue, 27 Aug 2013 09:04:38 -0400 Message-ID: <006e01cea325$fd3799c0$f7a6cd40$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJ/6HSZ0i2rb7Nzmzk2y2FpgUofqQMdQL0NAuVNhxsCYlbpoZgDU1AA X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:05:13 -0000 Or more appropriately ... PKI for Telecom Regulators. ( no they are not dummies) Seriously I was chatting with Hadriel privately and at some point given the scope of this effort a STIR FAQ document may be very very useful. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, August 27, 2013 8:52 AM To: 'Hadriel Kaplan'; 'Stephen Farrell' Cc: stir@ietf.org Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) +1 however a "shaken" list for not charter issues would not be unreasonable. It is a interesting thread and holds promise for future implementations. It is August after all. The charter is not yet approved. Conversations often become long winded. Ok question ... pretend you wanted a good primer "PKI for Teleco Dummies" any suggestions? Where would you start? Any good comparisons of various PKI implementations in the field? Successes failures etc? -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, August 26, 2013 8:40 PM To: Stephen Farrell Cc: stir@ietf.org WG Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) On Aug 26, 2013, at 5:14 PM, Stephen Farrell wrote: > I'm very confused by this whole thread. Do the folks advocating this extension of scope want to rerun the stir BoF in Vancouver? I don't think anyone has proposed that. (I hope?) > If not, please say how this fits the current draft charter. It doesn't. Richard Barnes sent in a request today for a separate mailing list for the calling name stuff. I don't know how long it takes to get one created though. > The reason for my concern btw is less process than a serious worry > that stir will fail if this is anywhere near the initial scope. yup. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Tue Aug 27 06:15:01 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A612F11E830B for ; Tue, 27 Aug 2013 06:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1-cW+ZQdXkH for ; Tue, 27 Aug 2013 06:14:56 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3F23F11E8302 for ; Tue, 27 Aug 2013 06:14:56 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7RDErdA011066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 13:14:55 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RDEqUt013893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 13:14:53 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RDEqAm023611; Tue, 27 Aug 2013 13:14:52 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 06:14:52 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <006e01cea325$fd3799c0$f7a6cd40$@shockey.us> Date: Tue, 27 Aug 2013 09:14:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3A130242-3F7A-4DCA-830E-9C8A5A1708B4@oracle.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <8CEA303F-7A29-4608-BF12-65F4F95BA74E@oracle.com> <005f01cea324$2b302a10$81907e30$@shockey.us> <006e01cea325$fd3799c0$f7a6cd40$@shockey.us> To: "Richard Shockey" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org WG" Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:15:01 -0000 I've written one - it's almost 30 pages. It includes a short bit on = what a PKI is, and its various flavors. I'll send it to you to see if it answers your questions well enough, or = if it needs more work. -hadriel On Aug 27, 2013, at 9:04 AM, "Richard Shockey" = wrote: >=20 > Or more appropriately ... PKI for Telecom Regulators. ( no they are = not > dummies) >=20 > Seriously I was chatting with Hadriel privately and at some point = given the > scope of this effort a STIR FAQ document may be very very useful.=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Richard Shockey > Sent: Tuesday, August 27, 2013 8:52 AM > To: 'Hadriel Kaplan'; 'Stephen Farrell' > Cc: stir@ietf.org > Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) >=20 > +1 however a "shaken" list for not charter issues would not be > unreasonable. It is a interesting thread and holds promise for future > implementations. >=20 > It is August after all. The charter is not yet approved. Conversations = often > become long winded. >=20 > Ok question ... pretend you wanted a good primer "PKI for Teleco = Dummies" > any suggestions? Where would you start? =20 >=20 > Any good comparisons of various PKI implementations in the field? > Successes failures etc?=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Hadriel Kaplan > Sent: Monday, August 26, 2013 8:40 PM > To: Stephen Farrell > Cc: stir@ietf.org WG > Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) >=20 >=20 > On Aug 26, 2013, at 5:14 PM, Stephen Farrell = > wrote: >=20 >> I'm very confused by this whole thread. Do the folks advocating this > extension of scope want to rerun the stir BoF in Vancouver? >=20 > I don't think anyone has proposed that. (I hope?) >=20 >=20 >> If not, please say how this fits the current draft charter. >=20 > It doesn't. Richard Barnes sent in a request today for a separate = mailing > list for the calling name stuff. I don't know how long it takes to = get one > created though. >=20 >=20 >> The reason for my concern btw is less process than a serious worry=20 >> that > stir will fail if this is anywhere near the initial scope. >=20 > yup. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From sanjay.mishra@verizon.com Tue Aug 27 06:18:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1F11E8324 for ; Tue, 27 Aug 2013 06:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=-2.208, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIclYeI6IsVK for ; Tue, 27 Aug 2013 06:18:40 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 873AD11E830B for ; Tue, 27 Aug 2013 06:18:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe03.verizonbusiness.com with ESMTP; 27 Aug 2013 13:18:24 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.89,968,1367971200"; d="scan'208,217";a="535343409" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 27 Aug 2013 13:18:23 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Tue, 27 Aug 2013 09:18:17 -0400 To: "stir@ietf.org" Date: Tue, 27 Aug 2013 09:18:16 -0400 Thread-Topic: WSJ article on the Robocall contest entry that was rejected by FTC Thread-Index: Ac6jJ+P9FZ01z4BvTGS+FhXF6lQrAA== Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C7967E2C3@FHDP1LUMXC7V23.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: multipart/alternative; boundary="_000_900A1E2059ADB149B905E3C8FA0046A62C7967E2C3FHDP1LUMXC7V2_" MIME-Version: 1.0 Subject: [stir] WSJ article on the Robocall contest entry that was rejected by FTC X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:18:47 -0000 --_000_900A1E2059ADB149B905E3C8FA0046A62C7967E2C3FHDP1LUMXC7V2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interesting take by Mr. Frankel who did not win the FTC contest for robocal= l (his entry was rejected)....He now wants his score. http://online.wsj.com/article/SB10001424127887323300004578557932773795900.h= tml?KEYWORDS=3Drobocall Thanks Sanjay --_000_900A1E2059ADB149B905E3C8FA0046A62C7967E2C3FHDP1LUMXC7V2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Interesting take= by Mr. Frankel who did not win the FTC contest for robocall (his entry was= rejected)….He now wants his score.

 

http://online.wsj.com/article/S= B10001424127887323300004578557932773795900.html?KEYWORDS=3Drobocall

 

Thank= s

Sanjay

 

 

= --_000_900A1E2059ADB149B905E3C8FA0046A62C7967E2C3FHDP1LUMXC7V2_-- From iesg-secretary@ietf.org Wed Aug 21 10:52:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1317E11E8242; Wed, 21 Aug 2013 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVaufqe9D71V; Wed, 21 Aug 2013 10:52:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2350A11E83D4; Wed, 21 Aug 2013 10:52:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130821175202.24713.10458.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 10:52:02 -0700 X-Mailman-Approved-At: Tue, 27 Aug 2013 08:39:21 -0700 Cc: stir WG Subject: [stir] WG Review: Secure Telephone Identity Revisited (stir) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:52:11 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-08-28. Secure Telephone Identity Revisited (stir) ------------------------------------------------ Current Status: Proposed WG Chairs: TBD Assigned Area Director: Richard Barnes Mailing list Address: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir Archive: http://www.ietf.org/mail-archive/web/stir/ Charter: The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or can lead to a return call at premium rates. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authorization to use telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify a SIP header-based mechanism for verification that the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used. This protection will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key that is associated with the one or more telephone numbers. Credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will consider a mechanism for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. Expansion of the authorization mechanism to identities using the user@domain form is out of scope. The work of this group is limited to developing a solution for telephone numbers. The working group will coordinate with the Security Area on credential management. The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments. The working group welcomes input from potential implementors or operators of technologies developed by this working group. For example, national numbering authorities might consider acting as credential authorities for telephone numbers within their purview. It is important to note that while the main focus of this working group is telephone numbers, the STIR working group will not develop any mechanisms that require changes to circuit-switched technologies. Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. In order to support anonymity, the working group will provide a solution in which the called party receives an indication that the source telephone number is unavailable. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to user agents or third parties than a call that does not make use of secure telephone identification mechanisms. Input to working group discussions shall include: - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks [RFC 3325] - Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) [RFC 4474] - Secure Call Origin Identification [draft-cooper-iab-secure-origin-00] - Secure Origin Identification: Problem Statement, Requirements, and Roadmap [draft-peterson-secure-origin-ps-00] - Authenticated Identity Management in the Session Initiation Protocol (SIP) [draft-jennings-dispatch-rfc4474bis-00] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on secure telephone identity - A threat model for the secure telephone identity mechanisms - A privacy analysis of the secure telephone identity mechanisms - A document describing the SIP in-band mechanism for telephone number-based identities during call setup - A document describing the credentials required to support telephone number identity authentication - A document describing the out-of-band mechanism for telephone number-based identities during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit threat model for Informational Nov 2013 Submit in-band mechanism for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Apr 2014 Submit Privacy analysis for Informational Jun 2014 Submit out-of-band mechanism for Proposed Standard From christopher.morrow@gmail.com Wed Aug 21 12:18:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C008021F9BD0; Wed, 21 Aug 2013 12:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap2ejhNv0mDs; Wed, 21 Aug 2013 12:18:24 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id B687F21F9F3D; Wed, 21 Aug 2013 12:18:19 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id u12so691123lbd.26 for ; Wed, 21 Aug 2013 12:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vDOd/6qrES4yp1m05LXxJwQfPfOip0VzcJzHpI/5jAw=; b=wFn5T2wGHe2GD3NLUc8swW3FZuolcFkdUTkXKqz5o2VaWIC8f3vbNuXFyB85SQN0/e 0xGDjAKOjaeBK+dlrsfbYEj8ETUM/2cCvPSWBNkw7TIpvqPkgyHOBVKP4xf3T8E9hqXA 97T/s8q+ilDpC7gzPkng4XayfyhTeDdd/53SR4KI3Kdug52lyINT/NMy2uUg12mCIimX ePcfdUHvCSGyTN85nGWx7A34wcNDZ5+Fbz96Am/Sy/rD5rJfIRfNw9JKWmSZD75Vg6P0 1HkvwiJipjcVny2AAgFIVrqHwEBonwvkHK8xrNmk4AkfuWUdO4p6AKthdjsOCamMQ3gh 9kqg== MIME-Version: 1.0 X-Received: by 10.112.57.49 with SMTP id f17mr8405809lbq.26.1377112698637; Wed, 21 Aug 2013 12:18:18 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.6.3 with HTTP; Wed, 21 Aug 2013 12:18:18 -0700 (PDT) In-Reply-To: <52150FD6.8010306@dcrocker.net> References: <20130821175202.24713.10458.idtracker@ietfa.amsl.com> <52150FD6.8010306@dcrocker.net> Date: Wed, 21 Aug 2013 15:18:18 -0400 X-Google-Sender-Auth: NXYYWtq26JbHbgTJaot5rRuEZLE Message-ID: From: Christopher Morrow To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 27 Aug 2013 08:39:21 -0700 Cc: stir WG , The IESG , ietf Subject: Re: [stir] WG Review: Secure Telephone Identity Revisited (stir) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:18:24 -0000 On Wed, Aug 21, 2013 at 3:07 PM, Dave Crocker wrote: > The following mostly are points that I raised within the group's mailing > list discussion, during charter development. In my view, they have not yet > been adequately resolved: > > > On 8/21/2013 10:52 AM, The IESG wrote: >> >> Please send your comments to the IESG mailing list (iesg >> at ietf.org) by 2013-08-28. > > ... >> >> The STIR working group will specify Internet-based mechanisms that allow >> verification of the calling party's authorization to use a particular >> telephone number for an incoming call. > > > "use a particular telephone number for an incoming call" has no obvious and it'd actually be kind of nice if the focus was NOT on the (us) 10-digit "number", but instead on the 'identity' making the call. There's a real chance to move beyond the '10-digit number' and to some stronger, wider, richer sense of 'identity'... we should take that opportunity and run with it. > unambiguous technical meaning. In fact, it seems to imply the meaning of > "authorization to call a particular number". However of course that's not > the intended meaning. Since this is the only text in this paragraph that > says what the working group will /do/ it should make its statement with > clarity and technical substance. > > That is, the charter needs to use a precise term for specifying the specific > role of the number of interest. In earlier drafts, "caller id" was used. s/number/identity/ > The next sentence uses "source telephone number". Perhaps that is > acceptable. no... focus on 'telephone number' is broken. Hell, it's not even what's used in the phone system anyway... not really. >> Since it has become fairly easy >> to present an incorrect source telephone number, a growing set of >> problems have emerged over the last decade. As with email, the claimed >> source identity of a SIP request is not verified, permitting unauthorized > > > As a matter of form, I'll note the SIP's community's use of "identity" is > what is called "identifier" in the identity community. > > ... > >> As its priority mechanism work item, the working group will specify a SIP > > > Reference to work priority is only meaningful in the face of a list of tasks > that will be considered simultaneously and what it means to give priority to > one over another. Based on the lengthy mailing list discussion of in-band > vs. out-of-band, it appears that the current charter is actually intended to > support simultaneous work on alternative mechanisms, rather than pursuing > them sequentially. > > This should be made explicit. If the requirement is to work on them > sequentially, then state that. If the intent is to work on both approaches > simultaneously, then say that. > > ... > > >> In addition to its priority mechanism work item, the working group will >> consider a mechanism for verification of the originator during session >> establishment in an environment with one or more non-SIP hops, most >> likely requiring an out-of-band authorization mechanism. However, the >> in-band and the out-of-band mechanisms should share as much in common as >> possible, especially the credentials. The in-band mechanism must be sent >> to the IESG for approval and publication prior to the out-of-band >> mechanism. > > > "in-band and the out-of-band mechanisms should share as much in common as > possible" > > This is the essential text that mandates working on both approaches > simultaneously and makes the earliet assertion about priority moot. (Note > how far down in the charter this is buried, yet how fundamental a > requirement is establishes.) > > > ... > >> Input to working group discussions shall include: >> > > That's a lengthy list of documents. Why has it left out other documents > discussed during charter development and clearly of continuing interest to > the effort, namely: > > A proposal for Caller Identity in a DNS-based Entrusted Registry > (CIDER) > draft-kaplan-stir-cider-00 > > An Identity Key-based and Effective Signature for Origin-Unknown > Types > draft-kaplan-stir-ikes-out-00 > > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net From medsalim.bouhlel@enis.rnu.tn Mon Aug 26 23:07:07 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945C711E8289 for ; Mon, 26 Aug 2013 23:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6bMxrx33-Bv for ; Mon, 26 Aug 2013 23:07:03 -0700 (PDT) Received: from cckmail40.outgw.tn (gwemail40.outgw.tn [193.95.97.187]) by ietfa.amsl.com (Postfix) with ESMTP id 240CC11E8125 for ; Mon, 26 Aug 2013 23:07:01 -0700 (PDT) Received: from cckmail20.outgw.tn (cckmail20.outgw.tn [193.95.97.158]) by cckmail40.outgw.tn (Postfix) with ESMTP id 98C9B2780232 for ; Tue, 27 Aug 2013 08:07:00 +0200 (CEST) Received: from smtp.rnrt.tn (unknown [196.203.79.188]) by cckmail20.outgw.tn (Postfix) with ESMTP id D9D25928002 for ; Tue, 27 Aug 2013 08:07:00 +0200 (CEST) Received: from smtp (smtp.rnu.tn [196.203.79.243]) by smtp.rnrt.tn (Postfix) with ESMTP id 4C952FAA000 for ; Tue, 27 Aug 2013 06:50:23 +0100 (CET) Received: from SETITPChome (unknown [41.226.205.99]) by smtp (Postfix) with ESMTP id 9E8D5636776 for ; Tue, 27 Aug 2013 07:08:51 +0100 (CET) MIME-Version: 1.0 From: "Global Premier International Conference on Cryptography and Security 2014" To: stir@ietf.org Content-Type: multipart/alternative; boundary="----=_NextPart_001_2A07_5D807F97.5EBB4041" X-Mailer: SendBlaster.1.5.5 Date: Tue, 27 Aug 2013 07:07:04 +0200 Message-ID: <7700221704392290029745@SETIT-PC> X-Mailman-Approved-At: Tue, 27 Aug 2013 08:39:21 -0700 Subject: [stir] Call For Papers : International Conference on Cryptography and Security / July 2014 - Bangkok/ X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: medsalim_bouhlel@yahoo.fr List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 06:07:07 -0000 ------=_NextPart_001_2A07_5D807F97.5EBB4041 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Appologies if you received multiple copies. Please consider to contribute and encourage your team members and fellow sc= ientists to contribute to the following events. Thanks for forwarding the information on this Call for Submissions to those= potentially interested to submit. Call for papers International Conference on Cryptography and Security 2014 18-20 July 2014 Holiday Inn Silom, Bangkok, Kingdom of Thailand=20 =20 In association with SETIT, Sfax University, Tunisia. and ASDF (Association = of Scientists, Developers and Faculties) Chennai Chapter, International Conference on Cryptography and Security 2014, is a main annua= l research conference aimed at presenting current research being carried ou= t. The idea of the conference is for the scientists, scholars, engineers an= d students from the Universities all around the world and the industry to p= resent ongoing research activities, and hence to foster research relations = between the Universities and the industry. ICCS2014 is co-sponsored by the Association of Scientists, Developers and F= aculties, India and SETIT, Sfax University, Tunisia and technical co-sponso= red by many other universities and institutes. The purpose of ICCS 2014, the International Conference on Cryptography and = Security, is to bring together researchers, mathematicians, engineers and p= ractitioners interested on security aspects related to information and comm= unication. Theoretical and practical advances in the fields of cryptography= and coding are a key factor in the growth of data communications, data net= works and distributed computing. In addition to the mathematical theory and= practice of cryptography and coding, ICCS also focuses on other aspects of= information systems and network security, including applications in the sc= ope of the knowledge society in general and information systems development= in particular, especially in the context of e-business, internet and globa= l enterprises.Areas of Conference Cryptography Data Security Network Security Encryption Technologies Watermarking =20 For more information visit : http://www.iccs.asdf.org.in/ or join us on Facebook : http://www.facebook.com/pages/International-Confer= ence-on-Cryptography-and-Security/450970385009899/ Best regards Mohamed Salim BOUHLEL General Co-Chair, ICCS2014 Head of Research Unit: Sciences & Technologies of Image and Telecommunicati= ons (Sfax University) GSM +216 20 20 00 05 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This email is sent out to all those on the SETIT database. If you want to b= e removed from this database, please send an email to unsubscribe.setit@gmail.com with subject Unsubscribe =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------=_NextPart_001_2A07_5D807F97.5EBB4041 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
=20

Appologies if you received multiple copies.
Please consi= der to contribute and encourage your team members and fellow scientists to = contribute to the following events.
Thanks for forwarding the informatio= n on this Call for Submissions to those potentially interested to submit.


Call for papers=
International Conference on Cryptography and Security 2014
18-20 Ju= ly 2014
Holiday Inn Silom, Bangkok, Kingdom of Thailand

 

In association with S= ETIT, Sfax University, Tunisia and ASDF= (Association of Scientists, Developers and Faculties), India.

International Conference on Cryptography and Security 201= 4, is a main annual research conference aimed at presenting current = research being carried out. The idea of the conference is for the scientist= s, scholars, engineers and students from the Universities all around the wo= rld and the industry to present ongoing research activities, and hence to f= oster research relations between the Universities and the industry.
ICCS2014 is co-sponsored by Association of Scient= ists, Developers and Faculties and SETIT, Sfax University, Tunisia and tech= nical co-sponsored by many other universities and institutes.
The purpo= se of ICCS2014 , the International Conference on Cryptography and Security,= is to bring together researchers, mathematicians, engineers and practition= ers interested on security aspects related to information and communication= . Theoretical and practical advances in the fields of cryptography and codi= ng are a key factor in the growth of data communications, data networks and= distributed computing. In addition to the mathematical theory and practice= of cryptography and coding, ICCS also focuses on other aspects of informat= ion systems and network security, including applications in the scope of th= e knowledge society in general and information systems development in parti= cular, especially in the context of e-business, internet and global enterpr= ises.Areas of Conference

  • Cryptography
  • Data Security
  • Network Security
  • Encryption Technologies
  • Watermarking

     

    For more information visit : http://www.iccs.asdf.org.in/

    or join us on Facebook : http://www.facebook.com/pages/International-Conference-= on-Cryptography-and-Security/450970385009899/

    Best regards

    Mohamed Salim BOUHLEL<= BR>General Co-Chair, ICCS2014,=  
    Head of Research Unit: Sciences & Technologies of Image and = Telecommunications (Sfax University)
    GSM +216 20 20 00 05

    3D"Add

    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
    This email is sent out to all those on the SETI= T database. If you want to be removed from this database, please send an em= ail
    to unsubscribe.setit= @gmail.com with subject Unsubscribe
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

    <= BR>

    •  ------=_NextPart_001_2A07_5D807F97.5EBB4041-- From michael.hammer@yaanatech.com Tue Aug 27 10:53:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF73E21E8096 for ; Tue, 27 Aug 2013 10:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAxysOPYzkBM for ; Tue, 27 Aug 2013 10:53:36 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id BC85721E8093 for ; Tue, 27 Aug 2013 10:53:36 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 27 Aug 2013 10:53:34 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "stephen.farrell@cs.tcd.ie" Thread-Topic: [stir] Reputation vs Display name (was Textual caller ID) Thread-Index: Ac6iitlyG+XmQi/1RiWQiKF6zs4RzAAUQ9+AAAcw5IAAFWaPIA== Date: Tue, 27 Aug 2013 17:53:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC2D45B@EX2K10MB1.corp.yaanatech.com> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <8CEA303F-7A29-4608-BF12-65F4F95BA74E@oracle.com> In-Reply-To: <8CEA303F-7A29-4608-BF12-65F4F95BA74E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.176] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0055_01CEA32C.D0E57430" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 17:53:41 -0000 ------=_NextPart_000_0055_01CEA32C.D0E57430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 STIR was getting derailed. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, August 26, 2013 8:40 PM To: Stephen Farrell Cc: stir@ietf.org WG Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) On Aug 26, 2013, at 5:14 PM, Stephen Farrell wrote: > I'm very confused by this whole thread. Do the folks advocating this extension of scope want to rerun the stir BoF in Vancouver? I don't think anyone has proposed that. (I hope?) > If not, please say how this fits the current draft charter. It doesn't. Richard Barnes sent in a request today for a separate mailing list for the calling name stuff. I don't know how long it takes to get one created though. > The reason for my concern btw is less process than a serious worry that stir will fail if this is anywhere near the initial scope. yup. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0055_01CEA32C.D0E57430 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgy NzE3NTMzMVowIwYJKoZIhvcNAQkEMRYEFIb62o/P5c4/DwSeEBRlbc+vr9z5MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEABd7akcsXa1eMLHTrOq0JeyX3TK8Lyl7dKvn+P7aU 6DKEDW5D5AmXBiXT/Q01bLT+RT9SOnj4GJiSejpc3mnE8hk2ye22rehh+HgPLqPO1WLSKYg0bmq6 7/c14qmEp2oNwiVpN3eLmWmukaICg0yVFxulC1E4lB9N2P7M+zQr/zNYWdxrg14o27mvsrrS5dz9 LnKpWwBBc9tkoeD5MDMuJGbFJqN/um76AYUk0go5rX2DRKs3MqG5wa5c0GCq4ZtvbJLNu4+OLa4Z 4pGI2MK+VKKchwe2Ad5ed8EfGV359gesk9XfUY8hnNEojUWvsjO3Pocu1gxBcsC6cLO7jK4QhgAA AAAAAA== ------=_NextPart_000_0055_01CEA32C.D0E57430-- From br@brianrosen.net Tue Aug 27 11:21:09 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AE521F9E37 for ; Tue, 27 Aug 2013 11:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f1AFCb86iV8 for ; Tue, 27 Aug 2013 11:21:05 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8B40021F9E3B for ; Tue, 27 Aug 2013 11:21:05 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so5151013pbb.19 for ; Tue, 27 Aug 2013 11:21:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rlA6DmpFBBLEDJ52ofJdPnwU0wci+U8NjlSxyf6cJrs=; b=YQiD4quhYcK4B0L2gQAHOc6ak2CKGn+rQDc0n08bB4yU5m6D3gU4v9vm0bz/Yw/Y+q 0qPFr7jZ5bs8u4zCnq5otBPHvxl6sS18bVC/LR/8xMb/t5whs81FN+mAl2YAxLMzBI2J HsJ2LYydMX3qiJiwdVa6eim4T6I4U8oBaMM/BPAmL6n0q5rw+yi85lxtoYFUsQDGANnd n2wl22lH3UouI0SiQSx3RHdHjd/Y6vJQZwHfX5vB58FAEa5U3t1TFIxyFyMQXtjuoqLq dDpyFSb5XxweDwY1Yx3bDmorp9UvInnNkuSibjVU78y/0ceA1TxTLdk+EOuKeCbMktBp vxew== X-Gm-Message-State: ALoCoQmThp03UPz1IZhma/RQUtcEyKBH7yN+MJisQ220VKjGO82w+f5U/H4nxn7Mv2V4s0CA7N90 MIME-Version: 1.0 X-Received: by 10.68.254.226 with SMTP id al2mr7878757pbd.157.1377627662643; Tue, 27 Aug 2013 11:21:02 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 27 Aug 2013 11:21:02 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> Date: Tue, 27 Aug 2013 14:21:02 -0400 Message-ID: From: Brian Rosen To: Alex Bobotek Content-Type: multipart/alternative; boundary=047d7b2e0fc777155504e4f1ef11 Cc: "stir@ietf.org" , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 18:21:10 -0000 --047d7b2e0fc777155504e4f1ef11 Content-Type: text/plain; charset=ISO-8859-1 Replying to this message that drifted the original thread. I personally want to keep this effort out of research and firmly in things we know how to do now. That means, to me, that reputation is not useful, because we don't have a notion of identity that we can work from, and we don't have any metrics that would allow us to build reputation systems for this application. We DO know how to do reasonable, but not entirely accurate, validation of names against numbers, especially if, as we can reasonably do, we get additional information from the origination service provider to do the validation. We do that now, pretty successfully. We can imagine extending the kinds of things we do now in the direction Tim, Henning, and others have suggested - primarily, the notion of having a taxonomy of callers (like "bank") and labeling the caller with the taxonomy in a reasonably accurate way. Based on the kinds of databases that exist, doing validation against an agreed upon taxonomy is not research. I think agreeing on the taxonomy is likely the hardest problem. But the kind of reputation systems I'm aware of would not give us an engineering basis to build equivalents for caller names, at least at present. Brian On Mon, Aug 26, 2013 at 2:26 PM, Alex Bobotek wrote: > Tim's point about duplicate names and Hadrial's about similar names are > important in anti-phishing and anti-spoofing contexts. Identity (e.g., > phone #), display name and reputation are different concepts. The display > name associated with a number may have some bearing on its reputation; > however, display name (e.g., "Example Bank" vs. "Examp1e Bank", duplicates > and similar variations) is insufficient to permit humans to reliably > discern reputation. > > I'm certainly not arguing against display names being certified by one or > more parties, or there being reputable number<-->name mapping databases. > I am arguing _for_ the optional inclusion of reputation information in a > larger framework. The end user can only to be protected from phishing and > spoofing by the inclusion of reputation information. > > This reputation should be associated with an _identity_ and may be based > on > * authorities' certifications of reputation (not just name) > * community-based reputation > * other means > > The reputation-based models implemented in some browsers, commercial > anti-virus solutions file reputation and DKIM/DMARC in email all bear some > relevance and are worth studying. > > IMHO, the model should allow for the inclusion of optional reputation > information, allowing screening, and user agent display and reporting. > > Regards, > > Alex Bobotek > alex@bobotek.net > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Friday, August 23, 2013 7:13 PM > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, > Early Homework) > > Just to clarify, as my original description obviously was lacking: > > I see two models, the "by-value" (display name or similar call-info > information) version, along the lines that Brian has been describing, and > the "by-reference" lookup model. > > For the latter, my rough notion is similar to whois - the (validated) > phone number becomes a key into one or more databases. Unlike CNAM, it > wouldn't be hard to have several, including ones operated by major carriers > and third-party certifiers (e.g., a regulatory agency, such as a financial > regulator, or professional licensing entity). Besides a query protocol that > end systems can execute, you don't need much. Primarily, the local bar > association needs to be able to ascertain that Attorney-at-Law Smith is > entitled to use the phone number he claims in his profile. > > For the by-value model, I see this as a useful generalization of the IKE > and 4474bis concepts, namely that a call request can have multiple > > (objects signed, signature, binding) > > headers. Thus, you could have > > (calling number, signature using STIR key, Date/To/...) > > as well as > > (display name, signature using PK of verizon.com, Date/To/...) > > This allows for the case that the carrier or a third party validates the > calling entity business name. This simply says "this is the name inserted > by the carrier, not the caller or some third party". Whether that is > sufficient to be useful depends on the policy of the signer. This requires > that the callee can verify that verizon.com is indeed the carrier of > record for this number. > > I don't think it's as useful to have the entity assigned the number use > its STIR key to sign, as that simply indicates that nobody else has messed > with the display information. > > I don't expect users to evaluate this - much of the filtering and scoring > will be done by third parties on behalf of the callee. If pinkcarrier.comsigns any garbage, this will land them on the do-not-trust list fairly > quickly and reputable businesses that prefer to not be tarred by that > behavior may decide to go elsewhere. > > We also seem to have no difficulty dealing with gray in spam filtering, as > in the scores that SpamAssassin attaches to messages. > > I don't see disagreement that verifiable names are not foolproof or can > prevent all fraudulent activity. I'm happy if it raises the bar or roughly > restores the level of trust that existed in the pre-VoIP days. > > Henning > > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Dwight, > Timothy M (Tim) [timothy.dwight@verizon.com] > Sent: Friday, August 23, 2013 3:38 PM > To: Hadriel Kaplan; Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, > Early Homework) > > Henning previously suggested what I understood to be a "database of names" > into which entities concerned that their name might be spoofed, could > register themselves. Banks for example. The idea was that to validate a > "calling name" you could look up that name in this database, and get in > return a list of phone numbers they've registered as numbers they use to > call people. You could then check to see if the [validated] calling number > was on that list. > > That seems to me to have at least one hole, though. Duplicate names. You > can't disallow them because in the real world it happens. But maybe in the > process of registering your name, you get a unique identifier. And that > identifier gets signaled in some new parameter, in addition to the textual > name. The validation function could then look up this identifier to > determine (a) what name should be displayed, and (b) whether the > [validated] calling number is registered as associated with that name. > > Brian is correct that I suggested the validation function might be on the > originating side of the call; which would require some way to carry the > result and the entity claiming to have produced that result, in the > signaling message. > > That doesn't of course prevent the terminating network validating it > again, if the entity claiming to have performed that validation, isn't > deemed trustworthy. > > I'm happy to take the topic of how best to authenticate calling name, to > another list. But if the initial STIR work specifies signaling > enhancements, I would like to see them include a way to convey the result > of a calling name validation performed somewhere upstream. Nothing about > how to do the validation [yet]. Let the folks who elect to post to this > other list, work on that. Just a container for the result. > > tim > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: Friday, August 23, 2013 1:44 PM > To: Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, > Early Homework) > > > On Aug 23, 2013, at 1:22 PM, Brian Rosen wrote: > > > The idea is that you get a 3rd party to provide the level of assurance, > hoping that the number of such services would be small and thus the > trustworhlyness of them being understood widely. The termination end can > decide if it trusts that third party, and, if necessary, use an alternative > service if it doesn't. > > We have that already today: just in the USA there are over a dozen LIDB > providers, and even more CNAM DB providers. The validity of the data in > them varies, but they're essentially the "3rd party" model. > > > > The reason to keep discussing this in stir is to emphasize that the > mechanism may need to carry some other data, like the assurance on the > name, in addition to what we're already discussing. > > That's a good point. > > One of the things we talked about originally was that a valid calling > number was a precursor to calling name, because the name lookup is based on > the calling number for the key. So I think for the current LIDB/CNAM > models the currently-proposed STIR in-band data is sufficient (or at least > I was thinking that way when I wrote the draft-IKES mechanism). > > Regardless, my concern is I can easily foresee a calling name discussion > knocking us off-the-tracks very quickly. For example I expect the > feature-creep to begin with including various other forms of name > identifiers, such as email or social-site-based names, and then getting > into the need for an IdP model, SSO/SAML/OpenID, OAuth, etc. Or we start > debating how to distinguish legitimate financial banks from blood banks and > sperm banks; or how users receiving just the string "Fidelity" disambiguate > when they get calls from: Fidelity Investments, Fidelity National > Financial, Fidelity National Information Services, USS Fidelity, Fidelity > Records, Fidelity IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, > Fidelity WFID, or Fidelity Township NJ. (all legal, separate entities in > the US) > > I don't really know how to prevent such ratholes, but maybe we need a > separate mailing list for the name discussions (i.e. for a > research/design-team) to separate that stuff out and keep this one focused > on the charter's scope? > > -hadriel > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7b2e0fc777155504e4f1ef11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    <we should be getting a new list shortly>
    Replyi= ng to this message that drifted the original thread.

    I personally want to keep this effort out of research and firmly in thin= gs we know how to do now. =A0That means, to me, that reputation is not usef= ul, because we don't have a notion of identity that we can work from, a= nd we don't have any metrics that would allow us to build reputation sy= stems for this application.=A0

    We DO know how to do reasonable, but not entirely accur= ate, validation of names against numbers, especially if, as we can reasonab= ly do, we get additional information from the origination service provider = to do the validation. =A0We do that now, pretty successfully. =A0We can ima= gine extending the kinds of things we do now in the direction Tim, Henning,= and others have suggested - primarily, the notion of having a taxonomy of = callers (like "bank") and labeling the caller with the taxonomy i= n a reasonably accurate way. =A0Based on the kinds of databases that exist,= doing validation against an agreed upon taxonomy is not research. =A0I thi= nk agreeing on the taxonomy is likely the hardest problem.

    But the kind of reputation systems I'm aware of wou= ld not give us an engineering basis to build equivalents for caller names, = at least at present.

    Brian



    On Mon,= Aug 26, 2013 at 2:26 PM, Alex Bobotek <alex@bobotek.net> wro= te:
    Tim's point about duplicate names and Ha= drial's about similar names are important in anti-phishing and anti-spo= ofing contexts. =A0Identity (e.g., phone #), display name and reputation ar= e different concepts. =A0 The display name associated with a number may hav= e some bearing on its reputation; however, display name =A0(e.g., "Exa= mple Bank" vs. "Examp1e Bank", duplicates and similar variat= ions) is insufficient to permit humans to reliably discern reputation.

    I'm certainly not arguing against display names being certified by one = or more parties, or there being reputable number<-->name mapping data= bases.
    I am arguing _for_ the optional inclusion of reputation information in a la= rger framework. =A0The end user can only to be protected from phishing and = spoofing by the inclusion of reputation information.

    This reputation should be associated with an _identity_ and =A0may be based= on
    * authorities' certifications of reputation (not just name)
    * community-based reputation
    * other means

    The reputation-based models implemented in some browsers, commercial anti-v= irus solutions file reputation =A0and DKIM/DMARC in email all bear some rel= evance and are worth studying.

    IMHO, the model should allow for the inclusion of optional reputation infor= mation, allowing screening, and user agent display and reporting.

    Regards,

    Alex Bobotek
    alex@bobotek.net

    -----Original Message-----
    From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] O= n Behalf Of Henning Schulzrinne
    Sent: Friday, August 23, 2013 7:13 PM
    To: Dwight, Timothy M (Tim); Hadriel Kaplan; Brian Rosen
    Cc: stir@ietf.org
    Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework)

    Just to clarify, as my original description obviously was lacking:

    I see two models, the "by-value" (display name or similar call-in= fo information) version, along the lines that Brian has been describing, an= d the "by-reference" lookup model.

    For the latter, my rough notion is similar to whois - the (validated) phone= number becomes a key into one or more databases. Unlike CNAM, it wouldn= 9;t be hard to have several, including ones operated by major carriers and = third-party certifiers (e.g., a regulatory agency, such as a financial regu= lator, or professional licensing entity). Besides a query protocol that end= systems can execute, you don't need much. Primarily, the local bar ass= ociation needs to be able to ascertain that Attorney-at-Law Smith is entitl= ed to use the phone number he claims in his profile.

    For the by-value model, I see this as a useful generalization of the IKE an= d 4474bis concepts, namely that a call request can have multiple

    (objects signed, signature, binding)

    headers. Thus, you could have

    (calling number, signature using STIR key, Date/To/...)

    as well as

    (display name, signature using PK of verizon.com, Date/To/...)

    This allows for the case that the carrier or a third party validates the ca= lling entity business name. This simply says "this is the name inserte= d by the carrier, not the caller or some third party". Whether that is= sufficient to be useful depends on the policy of the signer. This requires= that the callee can verify that verizon.com is indeed the carrier of record for this number.

    I don't think it's as useful to have the entity assigned the number= use its STIR key to sign, as that simply indicates that nobody else has me= ssed with the display information.

    I don't expect users to evaluate this - much of the filtering and scori= ng will be done by third parties on behalf of the callee. If pinkcarrier.com signs any garbag= e, this will land them on the do-not-trust list fairly quickly and reputabl= e businesses that prefer to not be tarred by that behavior may decide to go= elsewhere.

    We also seem to have no difficulty dealing with gray in spam filtering, as = in the scores that SpamAssassin attaches to messages.

    I don't see disagreement that verifiable names are not foolproof or can= prevent all fraudulent activity. I'm happy if it raises the bar or rou= ghly restores the level of trust that existed in the pre-VoIP days.

    Henning

    ________________________________________
    From: stir-bounces@ietf.org [<= a href=3D"mailto:stir-bounces@ietf.org">stir-bounces@ietf.org] on behal= f of Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]
    Sent: Friday, August 23, 2013 3:38 PM
    To: Hadriel Kaplan; Brian Rosen
    Cc: stir@ietf.org
    Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = =A0 =A0 =A0Early Homework)

    Henning previously suggested what I understood to be a "database of na= mes" into which entities concerned that their name might be spoofed, c= ould register themselves. =A0Banks for example. =A0The idea was that to val= idate a "calling name" you could look up that name in this databa= se, and get in return a list of phone numbers they've registered as num= bers they use to call people. =A0You could then check to see if the [valida= ted] calling number was on that list.

    That seems to me to have at least one hole, though. =A0Duplicate names. =A0= You can't disallow them because in the real world it happens. =A0But ma= ybe in the process of registering your name, you get a unique identifier. = =A0And that identifier gets signaled in some new parameter, in addition to = the textual name. =A0The validation function could then look up this identi= fier to determine (a) what name should be displayed, and (b) whether the [v= alidated] calling number is registered as associated with that name.

    Brian is correct that I suggested the validation function might be on the o= riginating side of the call; which would require some way to carry the resu= lt and the entity claiming to have produced that result, in the signaling m= essage.

    That doesn't of course prevent the terminating network validating it ag= ain, if the entity claiming to have performed that validation, isn't de= emed trustworthy.

    I'm happy to take the topic of how best to authenticate calling name, t= o another list. =A0But if the initial STIR work specifies signaling enhance= ments, I would like to see them include a way to convey the result of a cal= ling name validation performed somewhere upstream. =A0Nothing about how to = do the validation [yet]. =A0Let the folks who elect to post to this other l= ist, work on that. =A0Just a container for the result.

    tim

    -----Original Message-----
    From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] O= n Behalf Of Hadriel Kaplan
    Sent: Friday, August 23, 2013 1:44 PM
    To: Brian Rosen
    Cc: stir@ietf.org
    Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, = Early Homework)


    On Aug 23, 2013, at 1:22 PM, Brian Rosen <br@brianrosen.net> wrote:

    > The idea is that you get a 3rd party to provide the level of assurance= , hoping that the number of such services would be small and thus the trust= worhlyness of them being understood widely. =A0The termination end can deci= de if it trusts that third party, and, if necessary, use an alternative ser= vice if it doesn't.

    We have that already today: just in the USA there are over a dozen LIDB pro= viders, and even more CNAM DB providers. =A0The validity of the data in the= m varies, but they're essentially the "3rd party" model.


    > The reason to keep discussing this in stir is to emphasize that the me= chanism may need to carry some other data, like the assurance on the name, = in addition to what we're already discussing.

    That's a good point.

    One of the things we talked about originally was that a valid calling numbe= r was a precursor to calling name, because the name lookup is based on the = calling number for the key. =A0So I think for the current LIDB/CNAM models = the currently-proposed STIR in-band data is sufficient (or at least I was t= hinking that way when I wrote the draft-IKES mechanism).

    Regardless, my concern is I can easily foresee a calling name discussion kn= ocking us off-the-tracks very quickly. =A0For example I expect the feature-= creep to begin with including various other forms of name identifiers, such= as email or social-site-based names, and then getting into the need for an= IdP model, SSO/SAML/OpenID, OAuth, etc. =A0Or we start debating how to dis= tinguish legitimate financial banks from blood banks and sperm banks; or ho= w users receiving just the string "Fidelity" disambiguate when th= ey get calls from: Fidelity Investments, Fidelity National Financial, Fidel= ity National Information Services, USS Fidelity, Fidelity Records, Fidelity= IL, Fidelity MS, Fidelity Bldg MD, Fidelity Bldg TN, Fidelity WFID, or Fid= elity Township NJ. (all legal, separate entities in the US)

    I don't really know how to prevent such ratholes, but maybe we need a s= eparate mailing list for the name discussions (i.e. for a research/design-t= eam) to separate that stuff out and keep this one focused on the charter= 9;s scope?

    -hadriel

    _______________________________________________
    stir mailing list
    stir@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/stir
    _______________________________________________
    stir mailing list
    stir@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/stir
    _______________________________________________
    stir mailing list
    stir@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/stir

    --047d7b2e0fc777155504e4f1ef11-- From stephen.farrell@cs.tcd.ie Tue Aug 27 11:41:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEC421E80F3 for ; Tue, 27 Aug 2013 11:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjbIjBaRcoBi for ; Tue, 27 Aug 2013 11:41:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 77B4F11E81D7 for ; Tue, 27 Aug 2013 11:41:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B0E0BBE47; Tue, 27 Aug 2013 19:41:18 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-OGlh43g1Ie; Tue, 27 Aug 2013 19:41:17 +0100 (IST) Received: from [192.168.1.32] (nova010-184.cust-nat.nova.is [46.182.184.10]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 23C21BE4C; Tue, 27 Aug 2013 19:41:06 +0100 (IST) Message-ID: <521CF2B9.1050200@cs.tcd.ie> Date: Tue, 27 Aug 2013 18:40:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "stir@ietf.org" , Alex Bobotek , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 18:41:43 -0000 On þri 27.ágú 2013 18:21, Brian Rosen wrote: > > We DO know how to do reasonable, but not entirely accurate, validation > of names against numbers, especially if, as we can reasonably do, we > get additional information from the origination service provider to do > the validation. We do that now, pretty successfully. We can imagine > extending the kinds of things we do now in the direction Tim, Henning, > and others have suggested - primarily, the notion of having a taxonomy > of callers (like "bank") and labeling the caller with the taxonomy in > a reasonably accurate way. Based on the kinds of databases that > exist, doing validation against an agreed upon taxonomy is not research. FWIW, I don't think we know how to do that in a PKI (or DKIM-like equivalent) that is being established to issue credentials just for phone numbers. I think I saw Steve Kent say the same thing earlier as well. Dealing with people's names and businesses names like that just has a lot of complexity, or at least has had in any context in which I've encountered the problem. Just to throw one of many possible examples into the picture, the name Stiofán O'Fearghail would likely have to be accepted for me if an Irish regulator were deploying a STIR system that had to support people's names - are you saying you know how to handle all the i18n issues with naming that'd come up? S. From hadriel.kaplan@oracle.com Tue Aug 27 11:57:54 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B7F21F9DA9 for ; Tue, 27 Aug 2013 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCuIbypqub5d for ; Tue, 27 Aug 2013 11:57:39 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 156BA21F9DA1 for ; Tue, 27 Aug 2013 11:57:38 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7RIvbiE013955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Aug 2013 18:57:38 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RIvaVh011138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Aug 2013 18:57:37 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RIva8A000030 for ; Tue, 27 Aug 2013 18:57:36 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 11:57:36 -0700 From: Hadriel Kaplan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <82BB4D86-2393-4055-BE48-FCFA0D019156@oracle.com> Date: Tue, 27 Aug 2013 14:57:34 -0400 To: "stir@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [stir] Calling Name Identity Trust (CNIT) mailing list X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 18:57:54 -0000 A new IETF non-working group email list has been created. List address: cnit@ietf.org Archive: http://www.ietf.org/mail-archive/web/cnit/ To subscribe: https://www.ietf.org/mailman/listinfo/cnit Purpose: This list is for discussions relating to providing source = calling name identity for SIP-based call requests, in some trusted = fashion. This is currently a research item, and is related to the Secure = Telephone Identity Revisited (STIR) Working Group. STIR is for = validating source calling telephone numbers, while CNIT (pronounced = 'seen it' or 'can it') is for providing valid textual calling names. The list administrators are myself and Brian Rosen. -hadriel From br@brianrosen.net Tue Aug 27 12:01:56 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52F11E83E4 for ; Tue, 27 Aug 2013 12:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMZmvVHNRGv2 for ; Tue, 27 Aug 2013 12:01:44 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id DF9E011E837C for ; Tue, 27 Aug 2013 12:01:37 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf1so5223560pab.10 for ; Tue, 27 Aug 2013 12:01:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aYS6MNj/OCT7ftk12Og7N6YfvUb9L6NI4UIGG/gr+Qs=; b=Smt7AQeKa6y/xi/BnsBDsP01QqN0io8r5YveOrFfeEOr7SAJBho+PhyffCy2x8vjmt w8bj1XbAIsuqBk1c0YFaHGXl8AKdVzO2S4c4/vHzNEwiXQoHnKI+BSHcQ/6smTRAxKcO WLcCat5iXYwZ9GiOSeCMfuuViQwaKQq+mmTOzObncpICAbtLSjkYByXMGzwOIQzQ6/EF dohOnxs1TMcE6AGj1Cel+nB+6iIltGU7dyxKxrRStDHJnAFLrzszY8tqRZDMDxMsqm9v pkqpuacfuDkvufj87uROCJjPT0KeBeA7Kjnb3tO1AQVfSHxrqKVAEQh87gFtEjmCuPMj bNwA== X-Gm-Message-State: ALoCoQkselbsEzZXsSUsetdoQWXX9r7Cap+CTr3F2l89UxKFVNXNt+cphBRzaSDktQe9VeGzbCx7 MIME-Version: 1.0 X-Received: by 10.66.118.129 with SMTP id km1mr15932358pab.127.1377630096520; Tue, 27 Aug 2013 12:01:36 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 27 Aug 2013 12:01:36 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <521CF2B9.1050200@cs.tcd.ie> References: <4B1956260CD29F4A9622F00322FE053193812973D8@BOBO1A.bobotek.net> <521CF2B9.1050200@cs.tcd.ie> Date: Tue, 27 Aug 2013 15:01:36 -0400 Message-ID: From: Brian Rosen To: Stephen Farrell Content-Type: multipart/alternative; boundary=e89a8ffbab6b890af904e4f28020 Cc: "stir@ietf.org" , Alex Bobotek , Hadriel Kaplan , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne Subject: Re: [stir] Reputation vs Display name (was Textual caller ID) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 19:01:56 -0000 --e89a8ffbab6b890af904e4f28020 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No one suggested we do that in a PKI/DKIM that is issuing credentials for phone numbers. I merely wish to be able to carry the validation information as asserted by the entity signing the number. The validator service for the name is likely different from the number delegation authority. I repeat, often, that the mechanisms we use to do the name validation are not perfect, and they are most often local (i.e. a given validation database often only covers one, or a very small number of countries). If you attempted to use Stiof=E1n O'Fearghail assuming you presently resided i= n the U.S., you would get a very low score, unless you have regularly used that name in a variety of commercial circumstances or public records. Even if your birth certificate used that version of your name, if you didn't regularly use it, the database would score it low, even if you supplied other information about yourself. The same is very likely true of the databases that cover Ireland, unless, again, that was how you represented yourself commonly, especially in commercial transactions or public records, but I am less familiar with them than the U.S. databases. Each of these databases has different sources of data that it builds on, and they have different methods of correcting bad data. They are, however, pretty darn reliable over all, even though they are not perfect. I would not suggest that we standardize how these databases work. We only need to recognize that they exist, that they supply a score, and that they work better with more information suppled on a query, which leads me to try to get validation done at the origination side, where more information is typically available. We don't have to standardize queries to these databases, or anything other than the range of the score, where 0-100 is a generally acceptable range. Brian On Tue, Aug 27, 2013 at 2:40 PM, Stephen Farrell wrote: > On =FEri 27.=E1g=FA 2013 18:21, Brian Rosen wrote: > >> >> We DO know how to do reasonable, but not entirely accurate, validation o= f >> names against numbers, especially if, as we can reasonably do, we get >> additional information from the origination service provider to do the >> validation. We do that now, pretty successfully. We can imagine extend= ing >> the kinds of things we do now in the direction Tim, Henning, and others >> have suggested - primarily, the notion of having a taxonomy of callers >> (like "bank") and labeling the caller with the taxonomy in a reasonably >> accurate way. Based on the kinds of databases that exist, doing validat= ion >> against an agreed upon taxonomy is not research. >> > FWIW, I don't think we know how to do that in a PKI (or DKIM-like > equivalent) that is being established to issue credentials just for phone > numbers. I think I saw Steve Kent say the same thing earlier as well. > Dealing with people's > names and businesses names like that just has a lot of complexity, or at > least has had in any context in which I've encountered the problem. Just = to > throw one of many possible examples into the picture, the name Stiof=E1n > O'Fearghail would likely have to be accepted for me if an Irish regulator > were deploying a STIR system that had to support people's names - are you > saying you know how to handle all the i18n issues with naming that'd come > up? > > S. > > --e89a8ffbab6b890af904e4f28020 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    No one suggested we do that in a PKI/DKIM that is issuing = credentials for phone numbers. =A0I merely wish to be able to carry the val= idation information as asserted by the entity signing the number. =A0The va= lidator service for the name is likely different from the number delegation= authority. =A0

    I repeat, often, that the mechanisms we use to do the name v= alidation are not perfect, and they are most often local (i.e. a given vali= dation database often only covers one, or a very small number of countries)= . =A0If you attempted to use=A0Stiof=E1n O'Fearghail assuming you presently resided in= the U.S., you would get a very low score, unless you have regularly used t= hat name in a variety of commercial circumstances or public records. =A0Eve= n if your birth certificate used that version of your name, if you didn'= ;t regularly use it, the database would score it low, even if you supplied = other information about yourself. =A0The same is very likely true of the da= tabases that cover Ireland, unless, again, that was how you represented you= rself commonly, especially in commercial transactions or public records, bu= t I am less familiar with them than the U.S. databases.

    Eac= h of these databases has different sources of data that it builds on, and t= hey have different methods of correcting bad data. =A0They are, however, pr= etty darn reliable over all, even though they are not perfect. =A0 I would = not suggest that we standardize how these databases work. =A0We only need t= o recognize that they exist, that they supply a score, and that they work b= etter with more information suppled on a query, which leads me to try to ge= t validation done at the origination side, where more information is typica= lly available. =A0We don't have to standardize queries to these databas= es, or anything other than the range of the score, where 0-100 is a general= ly acceptable range.

    Bri= an




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

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

    S.


    --e89a8ffbab6b890af904e4f28020-- From br@brianrosen.net Tue Aug 27 12:14:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8998B21F9C1D for ; Tue, 27 Aug 2013 12:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYybmT+8IURr for ; Tue, 27 Aug 2013 12:14:06 -0700 (PDT) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id DDAF921F9A19 for ; Tue, 27 Aug 2013 12:14:06 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so5201934pbc.23 for ; Tue, 27 Aug 2013 12:14:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=95mpMkL0tj+KuvSk6I5aPxPL2K/sBFOtO16+4REGxm0=; b=LJZ2vsqgRr8FhxZxjPIzFVage0RR8j/acpZEBft13keWAILplzsg/1QphstEohIyFx 8uB/q4XLjFzTaGs/C1vdPib6vg3U7A8+HS7/EGPJvPLLkw6pKkWNufiFsn4Nn6n32fig R7xnlqkw2PQdtOdgSJk8bkenia4DTVZI4W4p4QhfoCxgIs5pVBzyvs/8aLrYZt7StPRF Ue2pD1fN3u9FtuXtssmuCo389juP+cRE/Jzslk8mlhX5rGDpNugSFZnIbeL3upypEKcN Qveu5vJK2b1FCe2Mc4s3pIw4tkiY0pDMvptz7hBDkbFH0ENK3PlhFYahX5SXfGP4TY3Q /P+g== X-Gm-Message-State: ALoCoQmco3gQwDtnjE6aMMNc21u1U4qaiooJztq8avSOw+Fat7xAyJVDAQdBPRZj5wbWzukauSvQ MIME-Version: 1.0 X-Received: by 10.68.143.38 with SMTP id sb6mr23135346pbb.44.1377630846699; Tue, 27 Aug 2013 12:14:06 -0700 (PDT) Received: by 10.70.73.69 with HTTP; Tue, 27 Aug 2013 12:14:06 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <82BB4D86-2393-4055-BE48-FCFA0D019156@oracle.com> References: <82BB4D86-2393-4055-BE48-FCFA0D019156@oracle.com> Date: Tue, 27 Aug 2013 15:14:06 -0400 Message-ID: From: Brian Rosen To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7b2e3fbe3fdcbb04e4f2ad2d Cc: "stir@ietf.org WG" Subject: Re: [stir] Calling Name Identity Trust (CNIT) mailing list X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 19:14:11 -0000 --047d7b2e3fbe3fdcbb04e4f2ad2d Content-Type: text/plain; charset=ISO-8859-1 If you reply to an existing thread on caller name, PLEASE change the " stir@ietf.org" to "cnit@ietf.org". Don't just blindly do reply all. Brian On Tue, Aug 27, 2013 at 2:57 PM, Hadriel Kaplan wrote: > A new IETF non-working group email list has been created. > > List address: cnit@ietf.org > Archive: http://www.ietf.org/mail-archive/web/cnit/ > To subscribe: https://www.ietf.org/mailman/listinfo/cnit > > Purpose: This list is for discussions relating to providing source calling > name identity for SIP-based call requests, in some trusted fashion. This is > currently a research item, and is related to the Secure Telephone Identity > Revisited (STIR) Working Group. STIR is for validating source calling > telephone numbers, while CNIT (pronounced 'seen it' or 'can it') is for > providing valid textual calling names. > > The list administrators are myself and Brian Rosen. > > -hadriel > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7b2e3fbe3fdcbb04e4f2ad2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    If you reply to an existing thread on caller name, PLEASE = change the "stir@ietf.org" t= o "cnit@ietf.org". =A0Don= 9;t just blindly do reply all.

    Brian


    On Tue, Aug 27, 2013 at 2:57 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:
    A new IETF non-working group email list has = been created.

    List address: cnit@ietf.org
    Archive: http://www.ietf.org/mail-archive/web/cnit/
    To subscribe: https://www.ietf.org/mailman/listinfo/cnit

    Purpose: This list is for discussions relating to providing source calling = name identity for SIP-based call requests, in some trusted fashion. This is= currently a research item, and is related to the Secure Telephone Identity= Revisited (STIR) Working Group. =A0STIR is for validating source calling t= elephone numbers, while CNIT (pronounced 'seen it' or 'can it&#= 39;) is for providing valid textual calling names.

    The list administrators are myself and Brian Rosen.

    -hadriel

    _______________________________________________
    stir mailing list
    stir@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/stir

    --047d7b2e3fbe3fdcbb04e4f2ad2d-- From kent@bbn.com Tue Aug 27 20:55:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ED211E812E for ; Tue, 27 Aug 2013 20:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noKGQx17JlHN for ; Tue, 27 Aug 2013 20:54:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id EBF0F11E812C for ; Tue, 27 Aug 2013 20:54:55 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:42722 helo=10.153.dhcp.conference.apricot.net) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VEWqK-000Nk2-HF; Tue, 27 Aug 2013 23:54:53 -0400 Message-ID: <521D7489.4010906@bbn.com> Date: Tue, 27 Aug 2013 23:54:49 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "stir@ietf.org" , "br@brianrosen.net" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 03:55:02 -0000 Brian, > ... > > Let me emphasize: > > All I want out of stir is a way to extend the signature to cover > whatever we come up with. That "whatever" can be done in a recharter > of stir, later, or it could be done in a separate WG, as long as we > can extend the signature to cover other stuff. > I am strongly opposed to what you have suggested above! For phone numbers we have a clear understanding of who is authoritative for what. For any other ID data, we do not. To place the phone number AND other data under the same signature potentially degrades the authentication offered for the phone number. So, in the words of a famous former first lady, "just say no." Steve From rlb@ipv.sx Wed Aug 28 06:27:32 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7031511E819E for ; Wed, 28 Aug 2013 06:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLsVZ3F5N3TJ for ; Wed, 28 Aug 2013 06:27:27 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB0311E8195 for ; Wed, 28 Aug 2013 06:27:27 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd6so6672614obb.19 for ; Wed, 28 Aug 2013 06:27:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yko89Twc7//MwOSz71hz6b28ukVV8Zz269FEJthlp/Y=; b=RbgOogM32xjryjo1PnFs1kFQYNd430KPScJE/y6kdxK8Df3G6AncBeAEIeZl6ji0ku p/rtR8Gwgm31TRC5SospvuH4EZV1APmAyXMGyZPLkB4SVUxpBsLWxz7mPmQJGqC7s+YG WQKWKqsaWXlWbDqNdqY0GQ2vwU1MUF2GbB6EGwNM9lX/w7voVXc37K9s6BYbYCwB/z2v o3TxitDcr7gOrpPOHaDZcAZ0Dkq0/5X9Zef7sGxTenqy0LYwnLzEEXStpwca3Dd+I1SC MXyZYhA2TisqSmjcFdjwPMcNthTV2vcq/pgdvthHgzTLbr3hMY/odaqpM5ipJPtTFvPz 9nGQ== X-Gm-Message-State: ALoCoQlIp7psNs5AeCwVxJRfioTrVpypeCvxVvxFIoaLnYHWR6dvwgp40ZOADMGvt+Huhn9+bcqg MIME-Version: 1.0 X-Received: by 10.182.81.65 with SMTP id y1mr6625354obx.89.1377696446974; Wed, 28 Aug 2013 06:27:26 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Wed, 28 Aug 2013 06:27:26 -0700 (PDT) X-Originating-IP: [192.1.51.95] In-Reply-To: <521D7489.4010906@bbn.com> References: <521D7489.4010906@bbn.com> Date: Wed, 28 Aug 2013 09:27:26 -0400 Message-ID: From: Richard Barnes To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b2e4d32549bb204e501f30f Cc: "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 13:27:33 -0000 --047d7b2e4d32549bb204e501f30f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 27, 2013 at 11:54 PM, Stephen Kent wrote: > Brian, > > ... >> >> >> Let me emphasize: >> >> All I want out of stir is a way to extend the signature to cover whatever >> we come up with. That "whatever" can be done in a recharter of stir, >> later, or it could be done in a separate WG, as long as we can extend the >> signature to cover other stuff. >> >> I am strongly opposed to what you have suggested above! For phone > numbers we have > a clear understanding of who is authoritative for what. For any other ID > data, we > do not. To place the phone number AND other data under the same signature > potentially > degrades the authentication offered for the phone number. > > So, in the words of a famous former first lady, "just say no." > > Steve > > Hey Steve, I think you might be a little confused here. There is an issue of trustworthiness here, but not one of authority. As I understand Brian's proposal, the idea would be to include (for example) naming information in a signed object that could be verified under a phone number credential. So the RP would know that the naming information is being asserted by the holder of the phone number, but *not* authoritatively. "The holder of +12125551212 says that her name is Chelsea." By way of analogy, this is kind of like the "Ghostbusters" record in the RPKI [1] -- the resource certificate used to verify that record attests only to authority for a set of Internet number resources, not any of the identifiers in the vCard in the record. Or, imagine that someone presented a driver's license with the name "Bradley" and said "... but call me Chelsea". Now, obviously you can't infer that naming information is actually true from the fact that it verifies under a phone number credential. But what you could do is go to some other service and say, "Phone number +1212555121 is asserting the name Chelsea, is that correct?", and they could tell you yes or no. So all we're really talking about here is a second way of getting verified additional information along with a phone number. In addition to: 1. Take the authenticated phone number and use it as a key to look up additional information from a trusted service ("Who is +12125551212?" "Bradley") (as we discussed earlier in this thread), we have: 2. Take the authenticated phone number and additional information provided by the caller, and have a trusted service verify it. ("Is 'Chelsea' a valid name for +15551212?" "Yes") In the first case, the third party service provides the information; in the second case, it only verifies it. (It could be argued that there's a privacy benefit to the second case, since the caller chooses what information is released. It also could provide a little more flexibility, as illustrated above.) In either case, though, it's clear that the phone number credential serves only to bind the additional information to the phone number. It does not imply any authority to assert the additional information; that authority needs to be come through some other channel. The only impact for STIR in any case is that if the second model is to be supported, then there has to be a way for the additional data to be included in the signed object. This will probably happen to some degree regardless, since the signed object will attest to SIP header values, of which the additional data could be one. But it might also be useful to include the additional data more directly, e.g., if will not survive in a SIP header. Anything in more detail than that is pretty speculative at this point, which is why we created the new CNIT list for discussion of things like the above two mechanisms. Hope this helps clarify, --Richard [1] --047d7b2e4d32549bb204e501f30f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    <hat type=3D"none"/>

    On Tue, Aug 27, 2013 at 11:54 PM, Stephen Kent <kent@bbn.com>= wrote:
    Bria= n,

    ...


    Let me emphasize:

    All I want out of stir is a way to extend the signature to cover whatever w= e come up with. =A0That "whatever" can be done in a recharter of = stir, later, or it could be done in a separate WG, as long as we can extend= the signature to cover other stuff.

    I am strongly opposed to what you have suggested above! For phone numbers w= e have
    a clear understanding of who is authoritative for what. For any other ID da= ta, we
    do not. To place the phone number AND other data under the same signature p= otentially
    degrades the authentication offered for the phone number.

    So, in the words of a famous former first lady, "just say no."
    Steve

    Hey Steve,

    I think you might be a lit= tle confused here. =A0There is an issue of trustworthiness here, but not on= e of authority. =A0

    As I understand Brian's proposal, the idea would be= to include (for example) naming information in a signed object that could = be verified under a phone number credential. =A0So the RP would know that t= he naming information is being asserted by the holder of the phone number, = but *not* authoritatively. =A0"The holder of +12125551212 says that he= r name is Chelsea."

    By way of analogy, this is kind of like the "Ghost= busters" record in the RPKI [1] -- the resource certificate used to ve= rify that record attests only to authority for a set of Internet number res= ources, not any of the identifiers in the vCard in the record. =A0Or, imagi= ne that someone presented a driver's license with the name "Bradle= y" and said "... but call me Chelsea".

    Now, obviously you can't infer that naming informat= ion is actually true from the fact that it verifies under a phone number cr= edential. =A0But what you could do is go to some other service and say, &qu= ot;Phone number +1212555121 is asserting the name Chelsea, is that correct?= ", and they could tell you yes or no.

    So all we're really talking about here is a second = way of getting verified additional information along with a phone number. = =A0In addition to:
    =A0 1. Take the authenticated phone number and= use it as a key to look up additional information from a trusted service (= "Who is +12125551212?" =A0"Bradley")
    (as we discussed earlier in this thread), we have:
    =A0 2. Ta= ke the authenticated phone number and additional information provided by th= e caller, and have a trusted service verify it. ("Is 'Chelsea'= a valid name for +15551212?" "Yes")

    In the first case, the third party service provides the= information; in the second case, it only verifies it. =A0(It could be argu= ed that there's a privacy benefit to the second case, since the caller = chooses what information is released. =A0It also could provide a little mor= e flexibility, as illustrated above.)

    In either case, though, it's clear that the phone n= umber credential serves only to bind the additional information to the phon= e number. =A0It does not imply any authority to assert the additional infor= mation; that authority needs to be come through some other channel.

    The only impact for STIR in any case is that if the sec= ond model is to be supported, then there has to be a way for the additional= data to be included in the signed object. =A0This will probably happen to = some degree regardless, since the signed object will attest to SIP header v= alues, of which the additional data could be one. =A0But it might also be u= seful to include the additional data more directly, e.g., if will not survi= ve in a SIP header.

    Anything in more detail than that is pretty speculative= at this point, which is why we created the new CNIT list for discussion of= things like the above two mechanisms.

    Hope this helps clarify,
    --Richard
    =

    --047d7b2e4d32549bb204e501f30f-- From pkyzivat@alum.mit.edu Wed Aug 28 07:01:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D593B11E819E for ; Wed, 28 Aug 2013 07:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq-tgjLlgQrj for ; Wed, 28 Aug 2013 07:01:31 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 10D1211E8195 for ; Wed, 28 Aug 2013 07:01:30 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta14.westchester.pa.mail.comcast.net with comcast id JCk81m0050QuhwU5EE1Wo0; Wed, 28 Aug 2013 14:01:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id JE1W1m00M3ZTu2S3NE1W4u; Wed, 28 Aug 2013 14:01:30 +0000 Message-ID: <521E02B9.4060902@alum.mit.edu> Date: Wed, 28 Aug 2013 10:01:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <521D7489.4010906@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377698490; bh=Q9xr/wKZWoGxHgOnSfHyN7AiCqoaNFHBN3MbN7KaeAU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WZq/hDrn/ju5GChXRnQFX86IkQ85ylSH0/nUsFEgxhmmd58szYuqJB1crjgWCicAm Mr/vfzzgSOugwf5TAgUk52yK02ZjK0UqI/3jDy0jC6yUA4BmGESbXt+WRBR8aPefS4 /x6KKwKvF6jLJ3ZpR/etGqrJYZ/jAE+HQ/oj0HcWUSQs4vLjap+aj2D5kf6VMGnfzp Q6gEw5rZiTWs5kXe3QVTXkVVX/0J/6wuSE4eRfNlvVptwwSZuBFkqYk1zRKnoEcUVS K+4r1m/3nErB6mi1l5hoJrrtK2EHMSCdMlzK+Web6joK5BCyQ28/uDIu0Mo09Rqs5/ JLF0m+L9dvGAQ== Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 14:01:36 -0000 Richard, I understand what you are saying below, but I don't see that it adds much extra value. Compare two cases: 1) as you describe below 2) only the number is signed. The caller still includes a display name, but it isn't signed. In the 2nd case, the recipient still gets a name and a number, and can still ask that other service whether the holder of the number can assert that name. The difference is that in the 2nd case the name could have been tampered with. But what difference does that make? It could mean that a good name was replaced by a bad one. But then it won't validate, and the callee will be presented with the number and no name. A tamperer who could do that could also remove the signature in the first case. Then the callee would not be presented with either number or name. Another possibility is that the caller has multiple names that it is permitted to use with the number. Then I suppose in (2) the tamperer could replace one valid name with another valid name. The callee would then see a name the caller didn't intend this callee to see. This wouldn't be possible with (1). But it is an obscure case, unlikely to be interesting to exploit. Bottom line, ISTM that this functionality adds some minor benefits that don't seem worth the trouble. Thanks, Paul On 8/28/13 9:27 AM, Richard Barnes wrote: > I think you might be a little confused here. There is an issue of > trustworthiness here, but not one of authority. > > As I understand Brian's proposal, the idea would be to include (for > example) naming information in a signed object that could be verified > under a phone number credential. So the RP would know that the naming > information is being asserted by the holder of the phone number, but > *not* authoritatively. "The holder of +12125551212 says that her name > is Chelsea." > > By way of analogy, this is kind of like the "Ghostbusters" record in the > RPKI [1] -- the resource certificate used to verify that record attests > only to authority for a set of Internet number resources, not any of the > identifiers in the vCard in the record. Or, imagine that someone > presented a driver's license with the name "Bradley" and said "... but > call me Chelsea". > > Now, obviously you can't infer that naming information is actually true > from the fact that it verifies under a phone number credential. But > what you could do is go to some other service and say, "Phone number > +1212555121 is asserting the name Chelsea, is that correct?", and they > could tell you yes or no. > > So all we're really talking about here is a second way of getting > verified additional information along with a phone number. In addition to: > 1. Take the authenticated phone number and use it as a key to look up > additional information from a trusted service ("Who is +12125551212?" > "Bradley") > (as we discussed earlier in this thread), we have: > 2. Take the authenticated phone number and additional information > provided by the caller, and have a trusted service verify it. ("Is > 'Chelsea' a valid name for +15551212?" "Yes") > > In the first case, the third party service provides the information; in > the second case, it only verifies it. (It could be argued that there's > a privacy benefit to the second case, since the caller chooses what > information is released. It also could provide a little more > flexibility, as illustrated above.) > > In either case, though, it's clear that the phone number credential > serves only to bind the additional information to the phone number. It > does not imply any authority to assert the additional information; that > authority needs to be come through some other channel. > > The only impact for STIR in any case is that if the second model is to > be supported, then there has to be a way for the additional data to be > included in the signed object. This will probably happen to some degree > regardless, since the signed object will attest to SIP header values, of > which the additional data could be one. But it might also be useful to > include the additional data more directly, e.g., if will not survive in > a SIP header. > > Anything in more detail than that is pretty speculative at this point, > which is why we created the new CNIT list for discussion of things like > the above two mechanisms. > > > Hope this helps clarify, > --Richard > > > [1] > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From rlb@ipv.sx Wed Aug 28 07:48:16 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B564B11E81BA for ; Wed, 28 Aug 2013 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwG+-KfQ3Q9F for ; Wed, 28 Aug 2013 07:48:12 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F721F9C87 for ; Wed, 28 Aug 2013 07:48:11 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so6868969obc.12 for ; Wed, 28 Aug 2013 07:48:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BYzfWWMdIkwNht4O3RoH91h3EsOlcA/E5lWqhuFbQdM=; b=eEvi3inzYk8TKxEweohSZy50IQlsbCyAmgdAFe+ANRPv2F2y9GQz1h1vs4YkKwtxUv M/aZFdPBkxkwe2v8B68tr+JK92kp1ZypVUkOvt++T/vByYDlKPxnARjcix6GONWKigLq HopQaob78U9864ou/Sf0AP46JIVXd9M1p7tOhqSy2lViYQvGxm4DwpBvNGOKlBXFyZ2q nSG+ZpCOUPbYvjJ1e39eYeTJQkYpZCmv3fThQX9tZH6DV+TuaGULcRq9M3dix3GpvBoJ b1+YLB/FWapsj45LYH9zT35R6aVnfNkM2/juhGCKRSR/T9/cSD9V70rfFwniiWAFZfKe AV8w== X-Gm-Message-State: ALoCoQlQaQnGDnC9NpjM7buB2jQY58r2pflH4A87yP7kS6CXZfOyHVeJurJYfiRXYjaBRDZN5+x1 MIME-Version: 1.0 X-Received: by 10.60.61.115 with SMTP id o19mr576811oer.85.1377701291379; Wed, 28 Aug 2013 07:48:11 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Wed, 28 Aug 2013 07:48:11 -0700 (PDT) X-Originating-IP: [192.1.51.95] In-Reply-To: <521E02B9.4060902@alum.mit.edu> References: <521D7489.4010906@bbn.com> <521E02B9.4060902@alum.mit.edu> Date: Wed, 28 Aug 2013 10:48:11 -0400 Message-ID: From: Richard Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1133073e145d8e04e50314d7 Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 14:48:16 -0000 --001a1133073e145d8e04e50314d7 Content-Type: text/plain; charset=ISO-8859-1 Agreed. The incremental benefit of having the asserted name covered by the signature is that the recipient knows that the caller added it, and not, say, some intermediate carrier. As to whether that's worthwhile information, YMMV. --Richard On Wed, Aug 28, 2013 at 10:01 AM, Paul Kyzivat wrote: > Richard, > > I understand what you are saying below, but I don't see that it adds much > extra value. > > Compare two cases: > > 1) as you describe below > 2) only the number is signed. The caller still includes a display > name, but it isn't signed. > > In the 2nd case, the recipient still gets a name and a number, and can > still ask that other service whether the holder of the number can assert > that name. > > The difference is that in the 2nd case the name could have been tampered > with. But what difference does that make? It could mean that a good name > was replaced by a bad one. But then it won't validate, and the callee will > be presented with the number and no name. > > A tamperer who could do that could also remove the signature in the first > case. Then the callee would not be presented with either number or name. > > Another possibility is that the caller has multiple names that it is > permitted to use with the number. Then I suppose in (2) the tamperer could > replace one valid name with another valid name. The callee would then see a > name the caller didn't intend this callee to see. This wouldn't be possible > with (1). But it is an obscure case, unlikely to be interesting to exploit. > > Bottom line, ISTM that this functionality adds some minor benefits that > don't seem worth the trouble. > > Thanks, > Paul > > > On 8/28/13 9:27 AM, Richard Barnes wrote: > > I think you might be a little confused here. There is an issue of >> trustworthiness here, but not one of authority. >> >> As I understand Brian's proposal, the idea would be to include (for >> example) naming information in a signed object that could be verified >> under a phone number credential. So the RP would know that the naming >> information is being asserted by the holder of the phone number, but >> *not* authoritatively. "The holder of +12125551212 says that her name >> is Chelsea." >> >> By way of analogy, this is kind of like the "Ghostbusters" record in the >> RPKI [1] -- the resource certificate used to verify that record attests >> only to authority for a set of Internet number resources, not any of the >> identifiers in the vCard in the record. Or, imagine that someone >> presented a driver's license with the name "Bradley" and said "... but >> call me Chelsea". >> >> Now, obviously you can't infer that naming information is actually true >> from the fact that it verifies under a phone number credential. But >> what you could do is go to some other service and say, "Phone number >> +1212555121 is asserting the name Chelsea, is that correct?", and they >> could tell you yes or no. >> >> So all we're really talking about here is a second way of getting >> verified additional information along with a phone number. In addition >> to: >> 1. Take the authenticated phone number and use it as a key to look up >> additional information from a trusted service ("Who is +12125551212?" >> "Bradley") >> (as we discussed earlier in this thread), we have: >> 2. Take the authenticated phone number and additional information >> provided by the caller, and have a trusted service verify it. ("Is >> 'Chelsea' a valid name for +15551212?" "Yes") >> >> In the first case, the third party service provides the information; in >> the second case, it only verifies it. (It could be argued that there's >> a privacy benefit to the second case, since the caller chooses what >> information is released. It also could provide a little more >> flexibility, as illustrated above.) >> >> In either case, though, it's clear that the phone number credential >> serves only to bind the additional information to the phone number. It >> does not imply any authority to assert the additional information; that >> authority needs to be come through some other channel. >> >> The only impact for STIR in any case is that if the second model is to >> be supported, then there has to be a way for the additional data to be >> included in the signed object. This will probably happen to some degree >> regardless, since the signed object will attest to SIP header values, of >> which the additional data could be one. But it might also be useful to >> include the additional data more directly, e.g., if will not survive in >> a SIP header. >> >> Anything in more detail than that is pretty speculative at this point, >> which is why we created the new CNIT list for discussion of things like >> the above two mechanisms. >> >> > >> >> Hope this helps clarify, >> --Richard >> >> >> [1] >> > >> >> >> ______________________________**_________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/**listinfo/stir >> >> > ______________________________**_________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/**listinfo/stir > --001a1133073e145d8e04e50314d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Agreed. =A0The incremental benefit of having the asse= rted name covered by the signature is that the recipient knows that the cal= ler added it, and not, say, some intermediate carrier. =A0As to whether tha= t's worthwhile information, YMMV.

    --Richard

    On Wed, Aug 28, 2013 at 10:01 AM, Paul Kyzivat = <pkyzivat@alum.mit.edu> wrote:
    Richard,

    I understand what you are saying below, but I don't see that it adds mu= ch extra value.

    Compare two cases:

    1) as you describe below
    2) only the number is signed. The caller still includes a display
    =A0 =A0name, but it isn't signed.

    In the 2nd case, the recipient still gets a name and a number, and can stil= l ask that other service whether the holder of the number can assert that n= ame.

    The difference is that in the 2nd case the name could have been tampered wi= th. But what difference does that make? It could mean that a good name was = replaced by a bad one. But then it won't validate, and the callee will = be presented with the number and no name.

    A tamperer who could do that could also remove the signature in the first c= ase. Then the callee would not be presented with either number or name.

    Another possibility is that the caller has multiple names that it is permit= ted to use with the number. Then I suppose in (2) the tamperer could replac= e one valid name with another valid name. The callee would then see a name = the caller didn't intend this callee to see. This wouldn't be possi= ble with (1). But it is an obscure case, unlikely to be interesting to expl= oit.

    Bottom line, ISTM that this functionality adds some minor benefits that don= 't seem worth the trouble.

    =A0 =A0 =A0 =A0 Thanks,
    =A0 =A0 =A0 =A0 Paul


    On 8/28/13 9:27 AM, Richard Barnes wrote:

    I think you might be a little confused here. =A0There is an issue of
    trustworthiness here, but not one of authority.

    As I understand Brian's proposal, the idea would be to include (for
    example) naming information in a signed object that could be verified
    under a phone number credential. =A0So the RP would know that the naming information is being asserted by the holder of the phone number, but
    *not* authoritatively. =A0"The holder of +12125551212 says that her n= ame
    is Chelsea."

    By way of analogy, this is kind of like the "Ghostbusters" record= in the
    RPKI [1] -- the resource certificate used to verify that record attests
    only to authority for a set of Internet number resources, not any of the identifiers in the vCard in the record. =A0Or, imagine that someone
    presented a driver's license with the name "Bradley" and said= "... but
    call me Chelsea".

    Now, obviously you can't infer that naming information is actually true=
    from the fact that it verifies under a phone number credential. =A0But
    what you could do is go to some other service and say, "Phone number +1212555121 is asserting the name Chelsea, is that correct?", and they=
    could tell you yes or no.

    So all we're really talking about here is a second way of getting
    verified additional information along with a phone number. =A0In addition t= o:
    =A0 =A01. Take the authenticated phone number and use it as a key to look u= p
    additional information from a trusted service ("Who is +12125551212?&= quot;
    =A0 "Bradley")
    (as we discussed earlier in this thread), we have:
    =A0 =A02. Take the authenticated phone number and additional information provided by the caller, and have a trusted service verify it. ("Is
    'Chelsea' a valid name for +15551212?" "Yes")

    In the first case, the third party service provides the information; in
    the second case, it only verifies it. =A0(It could be argued that there'= ;s
    a privacy benefit to the second case, since the caller chooses what
    information is released. =A0It also could provide a little more
    flexibility, as illustrated above.)

    In either case, though, it's clear that the phone number credential
    serves only to bind the additional information to the phone number. =A0It does not imply any authority to assert the additional information; that
    authority needs to be come through some other channel.

    The only impact for STIR in any case is that if the second model is to
    be supported, then there has to be a way for the additional data to be
    included in the signed object. =A0This will probably happen to some degree<= br> regardless, since the signed object will attest to SIP header values, of which the additional data could be one. =A0But it might also be useful to include the additional data more directly, e.g., if will not survive in
    a SIP header.

    Anything in more detail than that is pretty speculative at this point,
    which is why we created the new CNIT list for discussion of things like
    the above two mechanisms.
    <https://www.ietf.org/mailman/listinfo/cnit>

    Hope this helps clarify,
    --Richard


    [1] <ht= tp://tools.ietf.org/html/rfc6493>


    _______________________________________________
    stir mailing list
    stir@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/stir


    _______________________________________________
    stir mailing list
    stir@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/stir

    --001a1133073e145d8e04e50314d7-- From dhc@dcrocker.net Wed Aug 28 08:00:26 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB77711E81AB for ; Wed, 28 Aug 2013 08:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ2zu+Nb48ZT for ; Wed, 28 Aug 2013 08:00:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4C45B11E8197 for ; Wed, 28 Aug 2013 08:00:14 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7SF03MW000806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Aug 2013 08:00:06 -0700 Message-ID: <521E106F.7040709@dcrocker.net> Date: Wed, 28 Aug 2013 07:59:59 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Richard Barnes References: <521D7489.4010906@bbn.com> <521E02B9.4060902@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 28 Aug 2013 08:00:06 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 15:00:28 -0000 On 8/28/2013 7:48 AM, Richard Barnes wrote: > The incremental benefit of having the asserted name covered by the > signature is that the recipient knows that the caller added it As long as the semantics of the signature assert this explicitly, yes. By way of demonstrating this point, DKIM's semantics merely asserts that such adjunct information included in the signature hash was 'present' at the time of signing, rather than asserting its validity or even ownership by the signer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Wed Aug 28 08:34:28 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1002621F91BF for ; Wed, 28 Aug 2013 08:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgznQaX4x4DK for ; Wed, 28 Aug 2013 08:34:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7C36221F8EA8 for ; Wed, 28 Aug 2013 08:34:21 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7SFYHYG007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Aug 2013 15:34:18 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7SFYGaC021467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 15:34:17 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7SFYGQ4021401; Wed, 28 Aug 2013 15:34:16 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Aug 2013 08:34:16 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 28 Aug 2013 11:34:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2CD674FE-E37F-43D8-A220-25FAB4EE7C98@oracle.com> References: <521D7489.4010906@bbn.com> <521E02B9.4060902@alum.mit.edu> To: Richard Barnes X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 15:34:28 -0000 Exactly, but we've already ruled out malicious transit carriers for = STIR. -hadriel On Aug 28, 2013, at 10:48 AM, Richard Barnes wrote: > Agreed. The incremental benefit of having the asserted name covered = by the signature is that the recipient knows that the caller added it, = and not, say, some intermediate carrier. As to whether that's = worthwhile information, YMMV. >=20 > --Richard From kent@bbn.com Wed Aug 28 23:23:59 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1AA21F9FAB for ; Wed, 28 Aug 2013 23:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUnCnU2Aibi6 for ; Wed, 28 Aug 2013 23:23:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 70CC021F9F19 for ; Wed, 28 Aug 2013 23:23:53 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:48711 helo=10.153.dhcp.conference.apricot.net) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VEvdy-0008if-GJ; Thu, 29 Aug 2013 02:23:46 -0400 Message-ID: <521EE8F0.8080705@bbn.com> Date: Thu, 29 Aug 2013 02:23:44 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Richard Barnes References: <521D7489.4010906@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 06:24:00 -0000 Richard. > Hey Steve, > > I think you might be a little confused here. or you're a little confused about me being confused :-). > There is an issue of trustworthiness here, but not one of authority. not in all of the proposals I've seen. > As I understand Brian's proposal, the idea would be to include (for > example) naming information in a signed object that could be verified > under a phone number credential. So the RP would know that the naming > information is being asserted by the holder of the phone number, but > *not* authoritatively. "The holder of +12125551212 says that her name > is Chelsea." and that, IMHO, is a bad thing. We have a lot of experience that suggests that users will not appreciate this subtle distinction. > By way of analogy, this is kind of like the "Ghostbusters" record in > the RPKI [1] -- the resource certificate used to verify that record > attests only to authority for a set of Internet number resources, not > any of the identifiers in the vCard in the record. Or, imagine that > someone presented a driver's license with the name "Bradley" and said > "... but call me Chelsea". GB has minimal adverse effect if the signer of the record lies, compared to what we are talking about here. > Now, obviously you can't infer that naming information is actually > true from the fact that it verifies under a phone number credential. > But what you could do is go to some other service and say, "Phone > number +1212555121 is asserting the name Chelsea, is that correct?", > and they could tell you yes or no. yes, you could, that does not make it a good idea. > So all we're really talking about here is a second way of getting > verified additional information along with a phone number. In > addition to: > 1. Take the authenticated phone number and use it as a key to look > up additional information from a trusted service ("Who is > +12125551212?" "Bradley") > (as we discussed earlier in this thread), we have: > 2. Take the authenticated phone number and additional information > provided by the caller, and have a trusted service verify it. ("Is > 'Chelsea' a valid name for +15551212?" "Yes") yes, these are two options, but several others have been put forth. > In the first case, the third party service provides the information; > in the second case, it only verifies it. (It could be argued that > there's a privacy benefit to the second case, since the caller chooses > what information is released. It also could provide a little more > flexibility, as illustrated above.) agreed. > In either case, though, it's clear that the phone number credential > serves only to bind the additional information to the phone number. > It does not imply any authority to assert the additional information; > that authority needs to be come through some other channel. yes, but Brian suggested, at one point, that the originating SP should use the same key to sign both the number and an asserted name. That, I suggest, is a bad idea. > The only impact for STIR in any case is that if the second model is to > be supported, then there has to be a way for the additional data to be > included in the signed object. Which signed object? One generated by originating SP, one provided by the SP for the called party, or an object provided by a third party? (don't bother answering, as this is a rhetorical question.) > This will probably happen to some degree regardless, since the signed > object will attest to SIP header values, of which the additional data > could be one. But it might also be useful to include the additional > data more directly, e.g., if will not survive in a SIP header. maybe. > > Anything in more detail than that is pretty speculative at this point, > which is why we created the new CNIT list for discussion of things > like the above two mechanisms. > > > Hope this helps clarify, > --Richard I hope my replies help clarify my comments too. Steve From rlb@ipv.sx Fri Aug 30 09:41:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A464921E80EF for ; Fri, 30 Aug 2013 09:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5FTMZfcclLP for ; Fri, 30 Aug 2013 09:41:50 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id E6A0521E80E7 for ; Fri, 30 Aug 2013 09:41:46 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id i7so2562402oag.8 for ; Fri, 30 Aug 2013 09:41:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wKHCwFIsa0hlTPIl3+w028Vy5atD8YJFat9tX1dTpSM=; b=RqPfZVJDU0cKCNoL9X8qYNApnuzL439YtEWmJohFmtJ6hLWhsNT9bzhoLT+auIpWa3 NFCied/3X90u7PvZFn2Fr5hsoWrJLEbjND9y7Q4Xhn+rGyAJOvGAWsrEFeOjVooGkSd9 bSouBumpZlHlDKH9AMkdDaLfAF59eEFPRKItA/7/vSto+iOtEH/61FolqiqWmyhE4mVQ TEwV1O0vgK1T+GJYAppJvpCb0/jzlgWamSFhrLL5rW4dixE6nnSL278IBGbNH5BnpYZB BiWB+6mI7nNY92U0kEwwvDMN8PQFEaih+X9ycC1JsJcL0N94g2zB+sVx3Gqpy6IL7UBk /zEw== X-Gm-Message-State: ALoCoQn0c7P2iKCsjOMChumQGmpyKd+NzwcYDzJ5hwEvH3u4pzdBs3sjT8EedS8SvF1WZz7s/IAs MIME-Version: 1.0 X-Received: by 10.60.135.196 with SMTP id pu4mr965926oeb.89.1377880906444; Fri, 30 Aug 2013 09:41:46 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Fri, 30 Aug 2013 09:41:46 -0700 (PDT) X-Originating-IP: [192.1.51.95] In-Reply-To: <20130830162243.20403.56703.idtracker@ietfa.amsl.com> References: <20130830162243.20403.56703.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2013 12:41:46 -0400 Message-ID: From: Richard Barnes To: stir WG Content-Type: multipart/alternative; boundary=047d7b3a975cf8c2ac04e52ce5c8 Subject: Re: [stir] WG Action: Formed Secure Telephone Identity Revisited (stir) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:41:57 -0000 --047d7b3a975cf8c2ac04e52ce5c8 Content-Type: text/plain; charset=ISO-8859-1 We officially have a working group! Thanks to Russ and Robert for agreeing to chair. Now let's get to work! On Fri, Aug 30, 2013 at 12:22 PM, The IESG wrote: > A new IETF working group has been formed in the Real-time Applications > and Infrastructure Area. For additional information please contact the > Area Directors or the WG Chairs. > > Secure Telephone Identity Revisited (stir) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Robert Sparks > Russ Housley > > Assigned Area Director: > Richard Barnes > > Mailing list > Address: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir > Archive: http://www.ietf.org/mail-archive/web/stir/ > > Charter: > > The STIR working group will specify Internet-based mechanisms that allow > verification of the calling party's authorization to use a particular > telephone number for an incoming call. Since it has become fairly easy > to present an incorrect source telephone number, a growing set of > problems have emerged over the last decade. As with email, the claimed > source identity of a SIP request is not verified, permitting > unauthorized use of the source identity as part of deceptive and > coercive activities, such as robocalling (bulk unsolicited commercial > communications), vishing (voicemail hacking, and impersonating banks) > and swatting (impersonating callers to emergency services to stimulate > unwarranted large scale law enforcement deployments). In addition, use > of an incorrect source telephone number facilitates wire fraud or can > lead to a return call at premium rates. > > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working > group. To date, however, true validation of the source of SIP calls has > not seen any appreciable deployment. Several factors contributed to > this lack of success, including: failure of the problem to be seen as > critical at the time; lack of any technical means of producing a proof > of authorization to use telephone numbers; misalignment of the > mechanisms proposed by RFC 4474 with the complex deployment environment > that has emerged for SIP; lack of end-to-end SIP session establishment; > and inherent operational problems with a transitive trust model. To > make deployment of this solution more likely, consideration must be > given to latency, real-time performance, computational overhead, and > administrative overhead for the legitimate call source and all > verifiers. > > As its priority mechanism work item, the working group will specify a > SIP header-based mechanism for verification that the originator of a SIP > session is authorized to use the claimed source telephone number, where > the session is established with SIP end to end. This is called an in- > band mechanism. The mechanism will use a canonical telephone number > representation specified by the working group, including any mappings > that might be needed between the SIP header fields and the canonical > telephone number representation. The working group will consider > choices for protecting identity information and credentials used. This > protection will likely be based on a digital signature mechanism that > covers a set of information in the SIP header fields, and verification > will employ a credential that contains the public key that is associated > with the one or more telephone numbers. Credentials used with this > mechanism will be derived from existing telephone number assignment and > delegation models. That is, when a telephone number or range of > telephone numbers is delegated to an entity, relevant credentials will > be generated (or modified) to reflect such delegation. The mechanism > must allow a telephone number holder to further delegate and revoke use > of a telephone number without compromising the global delegation scheme. > > In addition to its priority mechanism work item, the working group will > consider a mechanism for verification of the originator during session > establishment in an environment with one or more non-SIP hops, most > likely requiring an out-of-band authorization mechanism. However, the > in-band and the out-of-band mechanisms should share as much in common as > possible, especially the credentials. The in-band mechanism must be > sent to the IESG for approval and publication prior to the out-of-band > mechanism. > > The work of this group is limited to developing a solution for telephone > numbers. Expansion of the authorization mechanism to identities using the > > user@domain or other name forms is out of scope. > > The working group will coordinate with the Security Area on credential > management and signature mechanics. > > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. > > The working group welcomes input from potential implementors or > operators of technologies developed by this working group. For example, > national numbering authorities might consider acting as credential > authorities for telephone numbers within their purview. > > It is important to note that while the main focus of this working group > is telephone numbers, the STIR working group will not develop any > mechanisms that require changes to circuit-switched technologies. > > Authentication and authorization of identity is closely linked to > privacy, and these security features sometimes come at the cost of > privacy. Anonymous calls are already defined in SIP standards, and this > working group will not propose changes to these standards. In order to > support anonymity, the working group will provide a solution in which > the called party receives an indication that the source telephone number > is unavailable. This working group, to the extent feasible, will > specify privacy-friendly mechanisms that do not reveal any more > information to user agents or third parties than a call that does not > make use of secure telephone identification mechanisms. > > Input to working group discussions shall include: > > - Private Extensions to the Session Initiation Protocol (SIP) > for Asserted Identity within Trusted Networks > [RFC 3325] > > - Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP) > [RFC 4474] > > - Secure Call Origin Identification > [draft-cooper-iab-secure-origin-00] > > - Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > [draft-peterson-secure-origin-ps-00] > > - Authenticated Identity Management in the Session Initiation > Protocol (SIP) > [draft-jennings-dispatch-rfc4474bis-00] > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situations that motivate work on secure telephone identity > > - A threat model for the secure telephone identity mechanisms > > - A privacy analysis of the secure telephone identity mechanisms > > - A document describing the SIP in-band mechanism for telephone > number-based identities during call setup > > - A document describing the credentials required to support > telephone number identity authentication > > - A document describing the out-of-band mechanism for telephone > number-based identities during call setup > > Milestones: > Sep 2013 - Submit problem statement for Informational > Nov 2013 - Submit threat model for Informational > Nov 2013 - Submit in-band mechanism for Proposed Standard > Feb 2014 - Submit credential specification for Proposed Standard > Apr 2014 - Submit Privacy analysis for Informational > Jun 2014 - Submit out-of-band mechanism for Proposed Standard > > > --047d7b3a975cf8c2ac04e52ce5c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    We officially have a working group! =A0Thanks to Russ and = Robert for agreeing to chair.

    Now let's get to work!=


    O= n Fri, Aug 30, 2013 at 12:22 PM, The IESG <iesg-secretary@ietf.org> wrote:
    A new IETF working group has been formed in = the Real-time Applications
    and Infrastructure Area. For additional information please contact the
    Area Directors or the WG Chairs.

    Secure Telephone Identity Revisited (stir)
    ------------------------------------------------
    Current Status: Proposed WG

    Chairs:
    =A0 Robert Sparks <    RjS@nostrum.com>
    =A0 Russ Housley <    housley@vigils= ec.com>

    Assigned Area Director:
    =A0 Richard Barnes <rlb@ipv.sx>

    Mailing list
    =A0 Address: stir@ietf.org
    =A0 To Subscribe: https://www.ietf.org/mailman/listinfo/stir
    =A0 Archive: http://www.ietf.org/mail-archive/web/stir/

    Charter:

    The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. =A0Since it has =A0become fairly eas= y
    to present an incorrect source telephone number, a growing set of
    problems have emerged over the last decade. =A0As with email, the claimed source identity of a SIP request is not verified, permitting
    unauthorized use of the source identity as part of deceptive and
    coercive activities, such as robocalling (bulk unsolicited commercial
    communications), vishing (voicemail hacking, and impersonating banks)
    and swatting (impersonating callers to emergency services to stimulate
    unwarranted large scale law enforcement deployments). =A0In addition, use of an incorrect source telephone number facilitates wire fraud or can
    lead to a return call at premium rates.

    SIP is one of the main VoIP technologies used by parties that want to
    present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP
    communications, including RFC 3325, RFC 4474, and the VIPR working
    group. =A0To date, however, true validation of the source of SIP calls has<= br> not seen any appreciable deployment. =A0Several factors contributed to
    this lack of success, including: failure of the problem to be seen as
    critical at the time; lack of any technical means of producing a proof
    of authorization to use telephone numbers; misalignment of the
    mechanisms proposed by RFC 4474 with the complex deployment environment
    that has emerged for SIP; lack of end-to-end SIP session establishment;
    and inherent operational problems with a transitive trust model. =A0To
    make deployment of this solution more likely, consideration must be
    given to latency, real-time performance, computational overhead, and
    administrative overhead for the legitimate call source and all
    verifiers.

    As its priority mechanism work item, the working group will specify a
    SIP header-based mechanism for verification that the originator of a SIP session is authorized to use the claimed source telephone number, where
    the session is established with SIP end to end. =A0This is called an in- band mechanism. The mechanism will use a canonical telephone number
    representation specified by the working group, including any mappings
    that =A0might be needed between the SIP header fields and the canonical
    telephone =A0number representation. =A0The working group will consider
    choices for protecting identity information and credentials used. =A0This protection will likely be based on a digital signature mechanism that
    covers a set of information in the SIP header fields, and verification
    will employ a credential that contains the public key that is associated with the one or more telephone numbers. =A0Credentials used with this
    mechanism will be derived from existing telephone number assignment and
    delegation models. =A0That is, when a telephone number or range of
    telephone numbers is delegated to an entity, relevant credentials will
    be generated (or modified) to reflect such delegation. =A0The mechanism
    must allow a telephone number holder to further delegate and revoke use
    of a telephone number without compromising the global delegation scheme.
    In addition to its priority mechanism work item, the working group will
    consider a mechanism for verification of the originator during session
    establishment in an environment with one or more non-SIP hops, most
    likely requiring an out-of-band authorization mechanism. =A0However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. =A0The in-band mechanism must be
    sent to the IESG for approval and publication prior to the out-of-band
    mechanism.

    The work of this group is limited to developing a solution for telephone numbers. Expansion of the authorization mechanism to identities using the
    user@domain or other name forms is out of scope.

    The working group will coordinate with the Security Area on credential
    management and signature mechanics.

    The working group will coordinate with other working groups in the RAI
    Area regarding signaling through existing deployments.

    The working group welcomes input from potential implementors or
    operators of technologies developed by this working group. =A0For example,<= br> national numbering authorities might consider acting as credential
    authorities for telephone numbers within their purview.

    It is important to note that while the main focus of this working group
    is telephone numbers, the STIR working group will not develop any
    mechanisms that require changes to circuit-switched technologies.

    Authentication and authorization of identity is closely linked to
    privacy, and these security features sometimes come at the cost of
    privacy. =A0Anonymous calls are already defined in SIP standards, and this<= br> working group will not propose changes to these standards. =A0In order to support anonymity, the working group will provide a solution in which
    the called party receives an indication that the source telephone number is unavailable. =A0This working group, to the extent feasible, will
    specify privacy-friendly mechanisms that do not reveal any more
    information to user agents or third parties than a call that does not
    make use of secure telephone identification mechanisms.

    Input to working group discussions shall include:

    =A0 - Private Extensions to the Session Initiation Protocol (SIP)
    =A0 =A0 for Asserted Identity within Trusted Networks
    =A0 =A0 [RFC 3325]

    =A0 - Enhancements for Authenticated Identity Management in the
    =A0 =A0 Session Initiation Protocol (SIP)
    =A0 =A0 [RFC 4474]

    =A0 - Secure Call Origin Identification
    =A0 =A0 [draft-cooper-iab-secure-origin-00]

    =A0 - Secure Origin Identification: Problem Statement, Requirements,
    =A0 =A0 and Roadmap
    =A0 =A0 [draft-peterson-secure-origin-ps-00]

    =A0 - Authenticated Identity Management in the Session Initiation
    =A0 =A0 Protocol (SIP)
    =A0 =A0 [draft-jennings-dispatch-rfc4474bis-00]

    The working group will deliver the following:

    =A0 - A problem statement detailing the deployment environment and
    =A0 =A0 situations that motivate work on secure telephone identity

    =A0 - A threat model for the secure telephone identity mechanisms

    =A0 - A privacy analysis of the secure telephone identity mechanisms

    =A0 - A document describing the SIP in-band mechanism for telephone
    =A0 =A0 number-based identities during call setup

    =A0 - A document describing the credentials required to support
    =A0 =A0 telephone number identity authentication

    =A0 - A document describing the out-of-band mechanism for telephone
    =A0 =A0 number-based identities during call setup

    Milestones:
    =A0 Sep 2013 - Submit problem statement for Informational
    =A0 Nov 2013 - Submit threat model for Informational
    =A0 Nov 2013 - Submit in-band mechanism for Proposed Standard
    =A0 Feb 2014 - Submit credential specification for Proposed Standard
    =A0 Apr 2014 - Submit Privacy analysis for Informational
    =A0 Jun 2014 - Submit out-of-band mechanism for Proposed Standard



    --047d7b3a975cf8c2ac04e52ce5c8-- From housley@vigilsec.com Fri Aug 30 11:29:38 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD00911E810E for ; Fri, 30 Aug 2013 11:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.098 X-Spam-Level: X-Spam-Status: No, score=-103.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImWzCPtqN4aS for ; Fri, 30 Aug 2013 11:29:32 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA1811E80FA for ; Fri, 30 Aug 2013 11:29:28 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 50E07F240FE for ; Fri, 30 Aug 2013 14:29:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id HgF4dloDrGVy for ; Fri, 30 Aug 2013 14:29:20 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3E379F240A7 for ; Fri, 30 Aug 2013 14:29:37 -0400 (EDT) From: Russ Housley Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-149-148200100 Date: Fri, 30 Aug 2013 14:29:18 -0400 In-Reply-To: To: stir WG References: <20130830162243.20403.56703.idtracker@ietfa.amsl.com> Message-Id: <6C0C2EF3-6AC1-42C3-A202-42C60865DB21@vigilsec.com> X-Mailer: Apple Mail (2.1085) Subject: Re: [stir] WG Action: Formed Secure Telephone Identity Revisited (stir) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 18:29:38 -0000 --Apple-Mail-149-148200100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The first document we need to work on is the problem statement. We have = seen an I-D for the BoF, but it included some things that need to move = to a threat document. Can the authors share the plan for that document? = Can we really get to WG consensus in four weeks? Russ On Aug 30, 2013, at 12:41 PM, Richard Barnes wrote: > We officially have a working group! Thanks to Russ and Robert for = agreeing to chair. >=20 > Now let's get to work! >=20 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situations that motivate work on secure telephone identity >=20 > - A threat model for the secure telephone identity mechanisms >=20 > - A privacy analysis of the secure telephone identity mechanisms >=20 > - A document describing the SIP in-band mechanism for telephone > number-based identities during call setup >=20 > - A document describing the credentials required to support > telephone number identity authentication >=20 > - A document describing the out-of-band mechanism for telephone > number-based identities during call setup >=20 > Milestones: > Sep 2013 - Submit problem statement for Informational > Nov 2013 - Submit threat model for Informational > Nov 2013 - Submit in-band mechanism for Proposed Standard > Feb 2014 - Submit credential specification for Proposed Standard > Apr 2014 - Submit Privacy analysis for Informational > Jun 2014 - Submit out-of-band mechanism for Proposed Standard >=20 --Apple-Mail-149-148200100 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = first document we need to work on is the problem statement.  We = have seen an I-D for the BoF, but it included some things that need to = move to a threat document.  Can the authors share the plan for that = document?  Can we really get to WG consensus in four = weeks?

    Russ


    On Aug 30, 2013, at 12:41 PM, Richard Barnes wrote:

    We officially have a working group!  Thanks to Russ and = Robert for agreeing to chair.

    Now let's get to = work!

    The working group will deliver the following:

      - A problem statement detailing the deployment environment = and
        situations that motivate work on secure telephone = identity

      - A threat model for the secure telephone identity mechanisms

      - A privacy analysis of the secure telephone identity = mechanisms

      - A document describing the SIP in-band mechanism for = telephone
        number-based identities during call setup

      - A document describing the credentials required to support
        telephone number identity authentication

      - A document describing the out-of-band mechanism for = telephone
        number-based identities during call setup

    Milestones:
      Sep 2013 - Submit problem statement for Informational
      Nov 2013 - Submit threat model for Informational
      Nov 2013 - Submit in-band mechanism for Proposed Standard
      Feb 2014 - Submit credential specification for Proposed = Standard
      Apr 2014 - Submit Privacy analysis for Informational
      Jun 2014 - Submit out-of-band mechanism for Proposed Standard
    =

    = --Apple-Mail-149-148200100--